使用插件还是油猴脚本
本文最后更新于：2020年12月30日 凌晨
场景
最近吾辈写了一个 chrome 插件，之前也有写过许多 user.js 脚本，所以便想在此谈一下它们的区别，以及如何选择。
简介
user.js 是一个开放的的标准，最早由 Firefox 的一个插件提出，后来在 chrome 得到原生支持。实际上，user.js 只是在用户的浏览器上访问一些网站时，向网站注入一些 JavaScript 脚本，除了顶部的声明信息以及一些 GM_* 的特殊 api 之外，它与普通的 JavaScript 没有什么不同。同时，目前支持 user.js 的浏览器插件很多，最流行的大概就是 TamperMonkey，同时支持非常多的浏览器，在不同浏览器之间实现了 跨平台。当然，为网页注入一段 JavaScript 脚本可以改变网页本身，但普通 JavaScript 做不到的事情，user.js 也基本没法实现。例如 获取所有的浏览器标签页 这种涉及到浏览器本身的操作。
而插件则不同，它是浏览器提供的一种附加功能，借用官方介绍：扩展程序是可定制浏览体验的小型软件程序。它们使用户可以根据个人需要或偏好来定制 Chrome 功能和行为。它们基于 Web 技术（例如 HTML，JavaScript 和 CSS）构建。，它们能访问浏览器众多的扩展 API，实现对浏览器级别的功能定制 – 而非仅限于网站。例如上面 user.js 做不到的事情 获取所有的浏览器标签页 浏览器插件可以轻易实现。
能力/API
相关 API 链接如下，此处就不贴了（太多了）
工程化
在工程化上，user.js 几乎没有工程化的最佳实践，直到目前为止，仍然没有简单可用的打包工具对 user.js 进行专门支持，例如通过 react 编写一些 UI 相关的内容并最终打包成一个 *.user.js 脚本文件是比较困难的。
看看目前的主流打包工具吧
- rollup: JavaScript SDK 打包工具
- Webpack: 最强大的打包工具
- parcel: 开箱可用的打包工具
是的，打包工具有不少，但这三者都对 user.js 没有太好的支持，主要有两点
- 保证打包后顶部信息说明注释仍然在最顶部
- 支持多入口打包
- 支持 TypeScript
- 支持 vue/react 现代前端框架
目前最合适的是 parcel，但仍然没有默认解决第一个问题。
与之相比，chrome 插件的工程化就要好上不少，parcel 甚至官方支持了 WebManifest 类型的资源，这对浏览器插件的开发有着极大的方便 – 可以使用现代前端的一切！
发布
user.js 可以发布在任何静态托管服务里，一般可以放在 GreasyFork 上，供需要的用户通过脚本管理其安装。GreasyFork 甚至可以直接导入 GitHub 上的源码和 README 发布一个脚本，同时在后续过程中自动更新。
而 chrome 插件则只能通过 chrome web store 进行分发，而且每次更新或上架都需要被审核，这其实是比较花时间的，并非是即时性的。同时 web store 也有注册费用，必须使用 Visa 等国外信用卡支付 $5，而这对于国内开发者而言是一件比较麻烦的事情。
吾辈知道可以使用开发者模式打开解压缩的插件，但这终究不是一个好的分发策略，不能要求每个用户都执行这种麻烦的操作，同时，每次重新打开浏览器都会进行提示也不厌其烦。
对于使用者
- 安装难度：chrome 插件安装事实上只能从 chrome store 就意味着国内用户几乎用不了，嗯，这点是一个相当的减分项。而油猴脚本则不太相同，只要支持 user.js 的插件即可添加任意多的 user.js 脚本，事实上，插件只是一个管理工具，chrome 原生支持它！
- 需求： 如果只是为网站诸如一段脚本修改一些网站的内容，则优先考虑使用 user.js，如果涉及到操作浏览器相关功能，则只能选择插件，本质上 user.js 在插件中就是 content script 功能。
- 性能：对于一般用户而言，安装一个 chrome 插件会一直在后台开启一个线程，而脚本不会 – 只会在需要生效的网站上应用。