背景
参考
还记得使用IE时期，这是一个ActiveX群魔乱舞的时代：各种软件通过ActiveX一键被安装进电脑，点几个网页就多装了好多个软件，特别酸爽。这是因为那个时期，JavaScript还不是特别强大，所以IE直接利用COM(组件对象模型)赋予开发者非常大的权限，去实现一些惊艳的功能。这些强大同样导致了特别严重的安全问题，很多插件拥有了不该拥有的能力。能够想象吗？随便开个网页，把我电脑的扫雷给自动打开了？
是的，IE显然把浏览器插件的路给走歪了。Google的Chrome扩展程序(Extension)主要使用JavaScript+HTML+CSS来进行构建。一个扩展程序和一个网站差不多，只不过用户在使用时不是直接网址访问，需要有个安装过程。在程序侧，由于被装到了用户本地，所以在状态维持上多了一些能力，同时给予程序一些浏览器层级的接口权限，但像直接打开扫雷的这种权限肯定是没有的。
下面就来介绍一下这个Chrome扩展程序(Extension)与普通网站不一样的地方。
关键文件
manifest.json
参考 index.html的<head>中的各种引用标签，就列出这个网页需要哪些资源。但对于一个代码工程而言，这个是非常有必要的。因为工程需要打包，需要知晓将哪些资源打进包里。于是在Chrome扩展程序(Extension)中的目录，manifest.json这个文件是必需的。
manifest.json中有特定结构，可以参照
popup.html
每个扩展被安装了之后，在浏览器的右上角会有一个小图标，当用户去点击这个图标的时候，会弹出一个页面，这个页面就被称作是popup，如下图所示。在manifest.json的配置中有专门一个字段用来指定该页面的路径。所以在扩展程序的目录结构中，需要有这样一个popup.html的网页文件。
background.js
这个文件是扩展程序的核心，一直处于运行状态，会接收来自popup.html等各处的消息，经过处理后进行存储，或者发回一些什么消息。这个文件在v2版本的manifest.json中可以指定为html页面，在v3版本中就只能指定为js文件了。这样设计也算合理，可能在v2版本的时候，ES6（ECMAScript 6.0）都还无法用，所以只能用一个html来加载多个js文件。在v3版本的时候，就直接可以用es6的import和export来加载整个工程了。
background.js的使用场景非常接近后端的API服务，原本需要发给API的请求，在扩展程序场景下可以全部都发给background.js。而且由于background.js是在本地的进程，不像远程接口那样有几十到几百毫秒的延时，每次交互都是秒回，体验特别好。
content scripts
由于popup.html需要在浏览器右上角打开，和用户的交互距离略微还有点远，毕竟不会常常去浏览器右上角点击。content scripts 则能完全贴着用户执行，比如在用户的右键上增加一些东西，在用户的网页上增加一些有利交互的HTML元素，甚至是直接修改用户网页的CSS/HTML等。content scripts是算作一个普通的js文件，没有很多的特权，所以很多事情，都要通过消息机制，发给background.js进行处理：比如跨域请求这种，只有background.js能执行，而content scripts需要遵循普通js的跨域限制。
options.html
popup.html只是一个在右上角的小页面创建，很多复杂的配置或交互都无法展开。如果扩展程序需要有一个自己的完整页面怎么办，就是options.html，如下图所示。
options.html的功能特性全部可以参照popup.html，按照一个普通的HTML页面去理解即可。
程序结构
按照上述的文件描述，一个最简单的Chrome扩展程序(Extension)的目录如下所示：
├── background.js
├── content-script.js
├── manifest.json
├── popup.html
└── popup.js