我毕业了，可惜工作没落实下来，不过最近找了个见习岗位也算临时安顿下自己的内心
我所在的岗位是客服，需要使用内网机整理运单和向上级汇报，刚开始做还行，新手保护期一过现在有些进程已经有些跟不上了
这里客服的工作框架就是有流程的点点点然后打电话反馈，所以我在想要是有什么一键脚本能帮我实现部分工作自动化就好了，剩下的时间可以跟上时代学点新东西
客服的所有流程都是跑在两个浏览器平台上的，一个是服务质量平台，还有一个是ERP平台，可惜那里的电脑是不能插u盘的，包括互联网也是不能上的，油猴那就是个奢望的存在
于是我就开始琢磨写浏览器脚本好了，好歹原生不卡环境，而且天助我也的是每台内网电脑都配了 Notepad++ 便于编程（其实后面我就直接用 Chrome 编程了，非常方便）
经过几天的摸索后，我发现 Chrome 留了一种神奇的开发方式，非常适合在内网中充当油猴的存在
当当！就是本文马上要谈及的 content.js ，有内网系统解放双手需求的小伙伴快快看过来
零. Chrome 也是 IDE
现在你就可以按下 Ctrl+Shift+I 或者 F12 进入 DevTools 了
一般用到 DevTools 的场景无非就是结合代码调整半成品界面，抑或是嗅探网络下点资源看，专业开发者或许会测试JS函数的性能还有结合 XPath 给 AI 做自动化用，但这次的主角不是一线功能 “元素” 和 “网络” ，也不是专业功能 “性能” 和 “Lighthouse” ，而是平平无奇的 “源代码/来源”
这个界面原本是给开发者调试网页用的，随着 Vite 这类热调试框架的流行，这个页面的功能其实有些食之无味了
但是我用的内网机可是没啥开发环境的，用这个就像捂在怀里有奶嗦（我这的方言顺口溜），有就不错了，何况它的功能也不差的
通过右上角切换成内容脚本后，可以见到我浏览器装的所有插件，每栏均可点进去看插件的源码（有的插件加了混淆其实看了没用）
下方关闭忽略列表后，可以对每个插件打上断点，获取插件的每个变量值，实不相瞒基本功能和我的 vscode 一样好用
接下来让我们切换“工作区”模式，咱们的 content.js 脚本就在这里动工
一. 不会吧我要上手写插件了么
Chrome 作为市值最大的浏览器，丰富多彩的插件生态就是受其滋润，俗称抱到大腿了
也基于此，Chrome的插件开发在浏览器三大家中也是比较规范的
Chrome的插件可以把它看作一个小公司，里面有三种工种
background.js
插件公司的大老板，负责统筹整个插件的运行方式，告诉其他两个角色该干啥活，并且掌管整个插件的记忆
MV2 时代它还能溜到后台静待其变
[!NOTE]+ 插件界不得不提一嘴 MV3
现在 MV3 把它叫做 Service Worker，不让它挂后台了，其他功能不变
这可能是 ublock origin 大削的重要原因毕竟它需要挂后台识别哪些请求是广告嘛
popup.js
插件公司的前台小妹，负责向用户展示插件运行情况，可以在插件一览中见到它
content.js
插件公司的牛马打工人，听从召唤对原有页面进行操作，注入或者抓取等
[!NOTE]+ 为啥大伙都是 js，html 去哪了
Chrome 插件界有个共识，HTML 需要与 JS 成对出行，不然会报错
HTML 不让夹带私货，倒是 JS 可以主动出击，所以谁是主角一目了然
而今天我们就要给牛马 content.js 展示自己的机会，没有花里胡哨的前台 popup.js ，也没有幕后将军 background.js ，现在就能开始
二. 写 content.js 是什么感觉
先介绍下一个最小的 Chrome 插件长啥样
在 manifest.json 中三行定义一下插件的名字、版本和使用的 manifest 版本（MV3或者MV2）
+{
+ "manifest_version": 3,
+ "name": "Content.js 插件测试",
+ "version": "1.0.0"
+}
[!NOTE]+ 还能再小吗
不行了，这三行组成的 manifest 配置就是 Chrome 接受的最小插件配置了
不信你去掉一行[!WARNING]- 不想试
然后就是添加对应 content.js 的时候了，再在底部加一行
{
"manifest_version": 3,
"name": "Content.js 插件测试",
"version": "1.0.0",
+ "content_scripts": [ {} ]
}
拿油猴举例，油猴可以支持不同的网站，靠的是顶部的网站筛选标签 // @match example.com/ ，同样的需要让 content.js 在指定网站上跑起来，就需要给定同样的 match 范围
{
"manifest_version": 3,
"name": "Content.js 插件测试",
"version": "1.0.0",
"content_scripts": [{
+ "matches": ["https://example.com/*"] // 支持用 * 作为通配符
}]
}
然后需要指定什么时候运行 content.js，Chrome 给出了三种场合 run_at 运行插件
document_start抢先在页面加载前运行，快人一步document_end页面加载好了，但要抢在页面数据（DOM）加载前运行，抢占先机document_idle页面数据加载好了，再启动插件，坐等渔翁之利
当然对于我这样需要 content.js 解放双手的，最常用的当然是 document_idle 哈
{
"manifest_version": 3,
"name": "Content.js 插件测试",
"version": "1.0.0",
"content_scripts": [{
"matches": ["https://example.com/*"],
+ "run_at": "document_idle" // 等数据都好了加载，最适合我
}]
}
最后当然是指定用哪个js作为插件啦，补上最后一句
{
"manifest_version": 3,
"name": "Content.js 插件测试",
"version": "1.0.0",
"content_scripts": [{
"matches": ["https://example.com/*"],
"run_at": "document_idle",
+ "js": ["content.js"]
}]
}
最后根据你的需要，给插件补上详情，或者更专业的加上些许权限，完成 manifest.json 的任务
{
"manifest_version": 3,
"name": "Content.js 插件测试",
"version": "1.0.0",
"description": "一个简单的Content.js 插件测试",
"content_scripts": [{
"matches": ["https://example.com/*"],
"run_at": "document_idle",
"js": ["content.js"]
}],
"permissions": ["storage"]
}
[!NOTE]+ 这个功能能不能拿来整理不同场合的插件
当然可以的，可以将相同场合的插件放到一起用，如下{ "content_scripts": [ { "matches": ["https://a.com/*"], "run_at": "document_idle", "js": ["content_a.js"] }, { "matches": ["https://b.com/*"], "run_at": "document_idle", "js": ["content_b.js"] } ] }
紧接着，别忘了在根目录下添加我们的 HelloWorld
// content.js
alert('HelloWorld');
就是这么简单，content.js 就会在我们指定的页面上运行了
今晚就写这么多，明天还要上班呢，明天分享一些 content.js 的实用小技巧
，也没有光驱
