【干货】Chrome插件(扩展)开发全攻略

我花了将近一个多月的时间断断续续写下这篇博文，并精心写下完整 demo，所以转载务必保留 http://blog.haoji.me/chrome-plugin-develop.html 。本文所有涉及到的大部分代码均在这个 demo 里面： https://github.com/sxei/chrome-plugin-demo ，大家可以直接下载下来运行。

另外，本文图片较多，请耐心等待加载完毕。

本文目录：

demo 部分截图：

什么是 Chrome 插件

严格来讲，我们正在说的东西应该叫 Chrome 扩展( Chrome Extension )，真正意义上的 Chrome 插件是更底层的浏览器功能扩展，可能需要对浏览器源码有一定掌握才有能力去开发。鉴于 Chrome 插件的叫法已经习惯，本文也全部采用这种叫法，但读者需深知本文所描述的 Chrome 插件实际上指的是 Chrome 扩展。

Chrome 插件是一个用 Web 技术开发、用来增强浏览器功能的软件，它其实就是一个由 HTML、CSS、JS、图片等资源组成的一个 .crx 后缀的压缩包.

个人猜测 crx 可能是 Chrome Extension 如下 3 个字母的简写：

另外，其实不只是前端技术，Chrome 插件还可以配合 C++编写的 dll 动态链接库实现一些更底层的功能(NPAPI)，比如全屏幕截图。

由于安全原因，Chrome 浏览器 42 以上版本已经陆续不再支持 NPAPI 插件，取而代之的是更安全的 PPAPI。

学习 Chrome 插件开发有什么意义

增强浏览器功能，轻松实现属于自己的“定制版”浏览器，等等。

Chrome 插件提供了很多实用 API 供我们使用，包括但不限于：

为什么是 Chrome 插件而不是 Firefox 插件

开发与调试

Chrome 插件没有严格的项目结构要求，只要保证本目录有一个 manifest.json 即可，也不需要专门的 IDE，普通的 web 开发工具即可。

从右上角菜单->更多工具->扩展程序可以进入 插件管理页面，也可以直接在地址栏输入 chrome://extensions 访问。

勾选 开发者模式 即可以文件夹的形式直接加载插件，否则只能安装 .crx 格式的文件。Chrome 要求插件必须从它的 Chrome 应用商店安装，其它任何网站下载的都无法直接安装，所以，其实我们可以把 crx 文件解压，然后通过开发者模式直接加载。

开发中，代码有任何改动都必须重新加载插件，只需要在插件管理页按下 Ctrl+R 即可，以防万一最好还把页面刷新一下。

manifest.json

这是一个 Chrome 插件最重要也是必不可少的文件，用来配置所有和插件相关的配置，必须放在根目录。其中， manifest_version 、 name 、 version 3 个是必不可少的， description 和 icons 是推荐的。

下面给出的是一些常见的配置项，均有中文注释，完整的配置文档请戳 这里 。

content-scripts

所谓 content-scripts ，其实就是 Chrome 插件中向页面注入脚本的一种形式（虽然名为 script，其实还可以包括 css 的），借助 content-scripts 我们可以实现通过配置的方式轻松向指定页面注入 JS 和 CSS（如果需要动态注入，可以参考下文），最常见的比如：广告屏蔽、页面 CSS 定制，等等。

示例配置：

特别注意，如果没有主动指定 run_at 为 document_start （默认为 document_idle ），下面这种代码是不会生效的：

content-scripts 和原始页面共享 DOM，但是不共享 JS，如要访问页面 JS（例如某个 JS 变量），只能通过 injected js 来实现。 content-scripts 不能访问绝大部分 chrome.xxx.api ，除了下面这 4 种：

其实看到这里不要悲观，这些 API 绝大部分时候都够用了，非要调用其它 API 的话，你还可以通过通信来实现让 background 来帮你调用（关于通信，后文有详细介绍）。

好了，Chrome 插件给我们提供了这么强大的 JS 注入功能，剩下的就是发挥你的想象力去玩弄浏览器了。

background

后台（姑且这么翻译吧），是一个常驻的页面，它的生命周期是插件中所有类型页面中最长的，它随着浏览器的打开而打开，随着浏览器的关闭而关闭，所以通常把需要一直运行的、启动就运行的、全局的代码放在 background 里面。

background 的权限非常高，几乎可以调用所有的 Chrome 扩展 API（除了 devtools），而且它可以无限制跨域，也就是可以跨域访问任何网站而无需要求对方设置 CORS 。

经过测试，其实不止是 background，所有的直接通过 chrome-extension://id/xx.html 这种方式打开的网页都可以无限制跨域。

配置中， background 可以通过 page 指定一张网页，也可以通过 scripts 直接指定一个 JS，Chrome 会自动为这个 JS 生成一个默认的网页：

需要特别说明的是，虽然你可以通过 chrome-extension://xxx/background.html 直接打开后台页，但是你打开的后台页和真正一直在后台运行的那个页面不是同一个，换句话说，你可以打开无数个 background.html ，但是真正在后台常驻的只有一个，而且这个你永远看不到它的界面，只能调试它的代码。

event-pages

这里顺带介绍一下 event-pages ，它是一个什么东西呢？鉴于 background 生命周期太长，长时间挂载后台可能会影响性能，所以 Google 又弄一个 event-pages ，在配置文件上，它与 background 的唯一区别就是多了一个 persistent 参数：

它的生命周期是：在被需要时加载，在空闲时被关闭，什么叫被需要时呢？比如第一次安装、插件更新、有 content-script 向它发送消息，等等。

除了配置文件的变化，代码上也有一些细微变化，个人这个简单了解一下就行了，一般情况下 background 也不会很消耗性能的。

popup

popup 是点击 browser_action 或者 page_action 图标时打开的一个小窗口网页，焦点离开网页就立即关闭，一般用来做一些临时性的交互。

popup 可以包含任意你想要的 HTML 内容，并且会自适应大小。可以通过 default_popup 字段来指定 popup 页面，也可以调用 setPopup() 方法。

配置方式：

需要特别注意的是，由于单击图标打开 popup，焦点离开又立即关闭，所以 popup 页面的生命周期一般很短，需要长时间运行的代码千万不要写在 popup 里面。

在权限上，它和 background 非常类似，它们之间最大的不同是生命周期的不同，popup 中可以直接通过 chrome.extension.getBackgroundPage() 获取 background 的 window 对象。

injected-script

这里的 injected-script 是我给它取的，指的是通过 DOM 操作的方式向页面注入的一种 JS。为什么要把这种 JS 单独拿出来讨论呢？又或者说为什么需要通过这种方式注入 JS 呢？

这是因为 content-script 有一个很大的“缺陷”，也就是无法访问页面中的 JS，虽然它可以操作 DOM，但是 DOM 却不能调用它，也就是无法在 DOM 中通过绑定事件的方式调用 content-script 中的代码（包括直接写 onclick 和 addEventListener 2 种方式都不行），但是，“在页面上添加一个按钮并调用插件的扩展 API”是一个很常见的需求，那该怎么办呢？其实这就是本小节要讲的。

在 content-script 中通过 DOM 方式向页面注入 inject-script 代码示例：

你以为这样就行了？执行一下你会看到如下报错：

意思就是你想要在 web 中直接访问插件中的资源的话必须显示声明才行，配置文件中增加如下：

至于 inject-script 如何调用 content-script 中的代码，后面我会在专门的一个消息通信章节详细介绍。

homepage_url

开发者或者插件主页设置，一般会在如下 2 个地方显示：

Chrome 插件的 8 种展示形式

browserAction(浏览器右上角)

通过配置 browser_action 可以在浏览器的右上角增加一个图标，一个 browser_action 可以拥有一个图标，一个 tooltip ，一个 badge 和一个 popup 。

示例配置如下：

browser_action 图标推荐使用宽高都为 19 像素的图片，更大的图标会被缩小，格式随意，一般推荐 png，可以通过 manifest 中 default_icon 字段配置，也可以调用 setIcon()方法。

tooltip

修改 browser_action 的 manifest 中 default_title 字段，或者调用 setTitle() 方法。

badge

所谓 badge 就是在图标上显示一些文本，可以用来更新一些小的扩展状态提示信息。因为 badge 空间有限，所以只支持 4 个以下的字符（英文 4 个，中文 2 个）。badge 无法通过配置文件来指定，必须通过代码实现，设置 badge 文字和颜色可以分别使用 setBadgeText() 和 setBadgeBackgroundColor() 。

pageAction(地址栏右侧)

所谓 pageAction ，指的是只有当某些特定页面打开才显示的图标，它和 browserAction 最大的区别是一个始终都显示，一个只在特定情况才显示。

需要特别说明的是早些版本的 Chrome 是将 pageAction 放在地址栏的最右边，左键单击弹出 popup，右键单击则弹出相关默认的选项菜单：

而新版的 Chrome 更改了这一策略，pageAction 和普通的 browserAction 一样也是放在浏览器右上角，只不过没有点亮时是灰色的，点亮了才是彩色的，灰色时无论左键还是右键单击都是弹出选项：

具体是从哪一版本开始改的没去仔细考究，反正知道 v50.0 的时候还是前者，v58.0 的时候已改为后者。

调整之后的 pageAction 我们可以简单地把它看成是可以置灰的 browserAction 。

示例(只有打开百度才显示图标)：

{
  "page_action":
  {
    "default_icon": "img/icon.png",
    "default_title": "我是pageAction",
    "default_popup": "popup.html"
  },
  "permissions": ["declarativeContent"]
}

// background.js
chrome.runtime.onInstalled.addListener(function(){
  chrome.declarativeContent.onPageChanged.removeRules(undefined, function(){
    chrome.declarativeContent.onPageChanged.addRules([
      {
        conditions: [
          // 只有打开百度才显示pageAction
          new chrome.declarativeContent.PageStateMatcher({pageUrl: {urlContains: 'baidu.com'}})
        ],
        actions: [new chrome.declarativeContent.ShowPageAction()]
      }
    ]);
  });
});

通过开发 Chrome 插件可以自定义浏览器的右键菜单，主要是通过 chrome.contextMenus API 实现，右键菜单可以出现在不同的上下文，比如普通页面、选中的文字、图片、链接，等等，如果有同一个插件里面定义了多个菜单，Chrome 会自动组合放到以插件名字命名的二级菜单里，如下：

最简单的右键菜单示例

{"permissions": ["contextMenus"]}

// background.js
chrome.contextMenus.create({
  title: "测试右键菜单",
  onclick: function(){alert('您点击了右键菜单！');}
});

添加右键百度搜索

{"permissions": ["contextMenus"， "tabs"]}

// background.js
chrome.contextMenus.create({
  title: '使用度娘搜索：%s', // %s表示选中的文字
  contexts: ['selection'], // 只有当选中文字时才会出现此右键菜单
  onclick: function(params)
  {
    // 注意不能使用location.href，因为location是属于background的window对象
    chrome.tabs.create({url: 'https://www.baidu.com/s?ie=utf-8&wd=' + encodeURI(params.selectionText)});
  }
});

效果如下：

这里只是简单列举一些常用的，完整 API 参见： https://developer.chrome.com/extensions/contextMenus

override(覆盖特定页面)

使用 override 页可以将 Chrome 默认的一些特定页面替换掉，改为使用扩展提供的页面。

扩展可以替代如下页面：

下面的截图是默认的新标签页和被扩展替换掉的新标签页。

代码（注意，一个插件只能替代一个默认页，以下仅为演示）：

devtools(开发者工具)

使用过 vue 的应该见过这种类型的插件：

是的，Chrome 允许插件在开发者工具(devtools)上动手脚，主要表现在：

先来看 2 张简单的 demo 截图，自定义面板（判断当前页面是否使用了 jQuery）：

自定义侧边栏（获取当前页面所有图片）：

devtools 扩展介绍

主页： https://developer.chrome.com/extensions/devtools

来一张官方图片：

每打开一个开发者工具窗口，都会创建 devtools 页面的实例，F12 窗口关闭，页面也随着关闭，所以 devtools 页面的生命周期和 devtools 窗口是一致的。devtools 页面可以访问一组特有的 DevTools API 以及有限的扩展 API，这组特有的 DevTools API 只有 devtools 页面才可以访问，background 都无权访问，这些 API 包括：

大部分扩展 API 都无法直接被 DevTools 页面调用，但它可以像 content-script 一样直接调用 chrome.extension 和 chrome.runtime API，同时它也可以像 content-script 一样使用 Message 交互的方式与 background 页面进行通信。

实例：创建一个 devtools 扩展

首先，要针对开发者工具开发插件，需要在清单文件声明如下：

这个 devtools.html 里面一般什么都没有，就引入一个 js：

可以看出来，其实真正代码是 devtools.js ，html 文件是“多余”的，所以这里觉得有点坑， devtools_page 干嘛不允许直接指定 JS 呢？

再来看 devtools.js 的代码：

setPage 时的效果：

以下截图示例的代码：

修改了 devtools 页面的代码时，需要先在 chrome://extensions 页面按下 Ctrl+R 重新加载插件，然后关闭再打开开发者工具即可，无需刷新页面（而且只刷新页面不刷新开发者工具的话是不会生效的）。

由于 devtools 本身就是开发者工具页面，所以几乎没有方法可以直接调试它，直接用 chrome-extension://extid/devtools.html" 的方式打开页面肯定报错，因为不支持相关特殊 API，只能先自己写一些方法屏蔽这些错误，调试通了再放开。

option(选项页)

所谓 options 页，就是插件的设置页面，有 2 个入口，一个是右键图标有一个“选项”菜单，还有一个在插件管理页面：

在 Chrome40 以前，options 页面和其它普通页面没什么区别，Chrome40 以后则有了一些变化。

我们先看老版的 options ：

这个页面里面的内容就随你自己发挥了，配置之后在插件管理页就会看到一个 选项 按钮入口，点进去就是打开一个网页，没啥好讲的。

再来看新版的 optionsV2 ：

options.html 的代码我们没有任何改动，只是配置文件改了，之后效果如下：

看起来是不是高大上了？

几点注意：

omnibox

omnibox 是向用户提供搜索建议的一种方式。先来看个 gif 图以便了解一下这东西到底是个什么鬼：

注册某个关键字以触发插件自己的搜索建议界面，然后可以任意发挥了。

首先，配置文件如下：

然后 background.js 中注册监听事件：

Chrome 提供了一个 chrome.notifications API 以便插件推送桌面通知，暂未找到 chrome.notifications 和 HTML5 自带的 Notification 的显著区别及优势。

在后台 JS 中，无论是使用 chrome.notifications 还是 Notification 都不需要申请权限（HTML5 方式需要申请权限），直接使用即可。

最简单的通知：

通知的样式可以很丰富：

这个没有深入研究，有需要的可以去看官方文档。

5 种类型的 JS 对比

Chrome 插件的 JS 主要可以分为这 5 类： injected script 、 content-script 、 popup js 、 background js 和 devtools js ，

调试方式对比

JS 类型	调试方式	图片说明
injected script	直接普通的 F12 即可	懒得截图
content-script	打开 Console,如图切换
popup-js	popup 页面右键审查元素
background	插件管理页点击背景页即可
devtools-js	暂未找到有效方法	-

通信主页： https://developer.chrome.com/extensions/messaging

前面我们介绍了 Chrome 插件中存在的 5 种 JS，那么它们之间如何互相通信呢？下面先来系统概况一下，然后再分类细说。需要知道的是，popup 和 background 其实几乎可以视为一种东西，因为它们可访问的 API 都一样、通信机制一样、都可以跨域。

互相通信概览

注： - 表示不存在或者无意义，或者待验证。

通信详细介绍

popup 和 background

popup 可以直接调用 background 中的 JS 方法，也可以直接访问 background 的 DOM：

function test() {




    
  alert("我是background！");
}

// popup.js
var bg = chrome.extension.getBackgroundPage();
bg.test(); // 访问bg的函数
alert(bg.document.body.innerHTML); // 访问bg的DOM

小插曲，今天碰到一个情况，发现 popup 无法获取 background 的任何方法，找了半天才发现是因为 background 的 js 报错了，而你如果不主动查看 background 的 js 的话，是看不到错误信息的，特此提醒。

至于 background 访问 popup 如下（前提是 popup 已经打开）：

popup 或者 bg 向 content 主动发送消息

background.js 或者 popup.js：

content-script.js 接收：

双方通信直接发送的都是 JSON 对象，不是 JSON 字符串，所以无需解析，很方便（当然也可以直接发送字符串）。

网上有些老代码中用的是 chrome.extension.onMessage ，没有完全查清二者的区别(貌似是别名)，但是建议统一使用 chrome.runtime.onMessage 。

content-script 主动发消息给后台

content-script.js：

background.js 或者 popup.js：

注意事项：

injected script 和 content-script

content-script 和页面内的脚本（ injected-script 自然也属于页面内的脚本）之间唯一共享的东西就是页面的 DOM 元素，有 2 种方法可以实现二者通讯：

第一种方法（推荐）：

injected-script 中：

content script 中：

第二种方法：

injected-script 中：

content-script.js 中：

长连接和短连接

其实上面已经涉及到了，这里再单独说明一下。Chrome 插件中有 2 种通信方式，一个是短连接（ chrome.tabs.sendMessage 和 chrome.runtime.sendMessage ），一个是长连接（ chrome.tabs.connect 和 chrome.runtime.connect ）。

短连接的话就是挤牙膏一样，我发送一下，你收到了再回复一下，如果对方不回复，你只能重新发，而长连接类似 WebSocket 会一直建立连接，双方可以随时互发消息。

短连接上面已经有代码示例了，这里只讲一下长连接。

popup.js：

content-script.js：

动态注入或执行 JS

虽然在 background 和 popup 中无法直接访问页面 DOM，但是可以通过 chrome.tabs.executeScript 来执行脚本，从而实现访问 web 页面的 DOM（注意，这种方式也不能直接访问页面 JS）。

示例 manifest.json 配置：

动态注入 CSS

示例 manifest.json 配置：

JS 代码：

获取当前窗口 ID

获取当前标签页 ID

一般有 2 种方法：

获取当前选项卡 id 的另一种方法，大部分时候都类似，只有少部分时候会不一样（例如当窗口最小化时）

本地存储建议用 chrome.storage 而不是普通的 localStorage ，区别有好几点，个人认为最重要的 2 点区别是：

需要声明 storage 权限，有 chrome.storage.sync 和 chrome.storage.local 2 种方式可供选择，使用示例如下：

webRequest

通过 webRequest 系列 API 可以对 HTTP 请求进行任性地修改、定制，这里通过 beforeRequest 来简单演示一下它的冰山一角：

{
  // 权限申请
  "permissions":
  [
    "webRequest", // web请求
    "webRequestBlocking", // 阻塞式web请求
    "storage", // 插件本地存储
    "http://*/*", // 可以通过executeScript或者insertCSS访问的网站
    "https://*/*" // 可以通过executeScript或者insertCSS访问的网站
  ],
}

// background.js
// 是否显示图片
var showImage;
chrome.storage.sync.get({showImage: true}, function(items) {
  showImage = items.showImage;
});
// web请求监听，最后一个参数表示阻塞式，需单独声明权限：webRequestBlocking
chrome.webRequest.onBeforeRequest.addListener(details => {
  // cancel 表示取消本次请求
  if(!showImage && details.type == 'image') return {cancel: true};
  // 简单的音视频检测
  // 大部分网站视频的type并不是media，且视频做了防下载处理，所以这里仅仅是为了演示效果，无实际意义
  if(details.type == 'media') {
    chrome.notifications.create(null, {
      type: 'basic',
      iconUrl: 'img/icon.png',
      title: '检测到音视频',
      message: '音视频地址：' + details.url,
    });
  }
}, {urls: ["<all_urls>"]}, ["blocking"]);

插件根目录新建一个名为 _locales 的文件夹，再在下面新建一些语言的文件夹，如 en 、 zh_CN 、 zh_TW ，然后再在每个文件夹放入一个 messages.json ，同时必须在清单文件中设置 default_locale 。

_locales\en\messages.json 内容：

_locales\zh_CN\messages.json 内容：

在 manifest.json 和 CSS 文件中通过 __MSG_messagename__ 引入，如：

JS 中则直接 chrome.i18n.getMessage("helloWorld") 。

测试时，通过给 chrome 建立一个不同的快捷方式 chrome.exe --lang=en 来切换语言，如：

英文效果：

中文效果：

API 总结

比较常用用的一些 API 系列：

查看已安装插件路径

已安装的插件源码路径： C:\Users\用户名\AppData\Local\Google\Chrome\User Data\Default\Extensions ，每一个插件被放在以插件 ID 为名的文件夹里面，想要学习某个插件的某个功能是如何实现的，看人家的源码是最好的方法了：

如何查看某个插件的 ID？进入 chrome://extensions ，然后勾线开发者模式即可看到了。

特别注意 background 的报错

很多时候你发现你的代码会莫名其妙的失效，找来找去又找不到原因，这时打开 background 的控制台才发现原来某个地方写错了导致代码没生效，正式由于 background 报错的隐蔽性(需要主动打开对应的控制台才能看到错误)，所以特别注意这点。

如何让 popup 页面不关闭

在对 popup 页面审查元素的时候 popup 会被强制打开无法关闭，只有控制台关闭了才可以关闭 popup，原因很简单：如果 popup 关闭了控制台就没用了。这种方法在某些情况下很实用！

不支持内联 JavaScript 的执行

也就是不支持将 js 直接写在 html 中，比如：

报错如下：

解决方法就是用 JS 绑定事件：

另外，对于 A 标签，这样写 href="javascript:;" 然后用 JS 绑定事件虽然控制台会报错，但是不受影响，当然强迫症患者受不了的话只能写成 href="#" 了。

如果这样写：

报错如下：

注入 CSS 的时候必须小心

由于通过 content_scripts 注入的 CSS 优先级非常高，几乎仅次于浏览器默认样式，稍不注意可能就会影响一些网站的展示效果，所以尽量不要写一些影响全局的样式。

之所以强调这个，是因为这个带来的问题非常隐蔽，不太容易找到，可能你正在写某个网页，昨天样式还是好好的，怎么今天就突然不行了？然后你辛辛苦苦找来找去，找了半天才发现竟然是因为插件里面的一个样式影响的！

打包与发布

打包的话直接在插件管理页有一个打包按钮：

然后会生成一个 .crx 文件，要发布到 Google 应用商店的话需要先登录你的 Google 账号，然后花 5 个$注册为开发者，本人太穷，就懒得亲自验证了，有发布需求的自己去整吧。

推荐查看官方文档，虽然是英文，但是全且新，国内的中文资料都比较旧（注意以下全部需要翻墙）：

第三方资料

部分中文资料，不是特别推荐：