油猴脚本的世界：Tampermonkey 是什么、脚本市场怎么逛

「油猴」是 Tampermonkey 在中文圈的昵称，这个名字来自它更老的前辈 Greasemonkey（ greasy monkey，油滑的猴子）。它本质上是一个浏览器扩展，但它的职业是「脚本管理器」：替你安装、启用、禁用、更新成千上万个来自社区的小脚本。想理解扩展生态，先逛明白油猴的世界是最快的热身。

Tampermonkey 的角色

用户脚本本身只是一段文本，谁来实现「把这段文本安装进浏览器、在匹配的页面自动执行」？答案就是管理器。Tampermonkey 支持 Chrome、Edge、Firefox、Safari 等主流浏览器，是事实上的行业标准。它提供了：

• 脚本的安装、开关、分组、自动更新；
• 一套 GM_* 特权 API（跨域请求、存储、样式注入等）；
• 内置编辑器，写完保存即生效；
• 兼容 Greasemonkey 时代的元数据协议。

从一个事实就能看出它的地位：Chrome 官方扩展商店里 Tampermonkey 长期位居用户量最大的扩展之列。对开发者而言，它还有一层意义——GM_* API 与扩展的 chrome API 概念相通，先写脚本再迁移到扩展是最平滑的成长路径。

脚本从哪来：三大渠道

用户脚本没有官方商店，社区主要靠这几个渠道流通：

逛脚本站的基本动作是搜站点域名而不是功能名。比如想让某视频网站支持倍速，直接搜该网站域名，命中率高得多。每个脚本页都会展示安装量、版本、适用站点和历史更新日志，安装量高且更新频繁的脚本通常更可靠。

装之前必做的三件事

用户脚本没有任何官方审核，安装等于把你的一段代码放进了浏览器，它能访问你打开的每个匹配页面。所以装之前养成三个习惯：

1. 读元数据头。看 @match 覆盖了哪些网站，范围远超它的功能所需就要警惕——一个去广告脚本不该要求所有网站的权限。
2. 扫一遍代码。重点搜 GM_xmlhttpRequest、eval、document.cookie 这几个点，看它们把数据发到哪里。大部分恶意脚本会在跨域请求里现出原形。
3. 看更新时间。网站改版会让老脚本失效甚至误伤，超过一年没更新的脚本要谨慎。

学会了辨别，你就掌握了「用」的层面。下一步自然是「写」——这也是本教程的重心。第二章会从安装面板讲起，把元数据头、GM API 和三个完整案例过一遍。

为什么先学脚本再学扩展

有三个很实际的理由。第一，反馈快：脚本保存即生效，不用打包、不用重新加载扩展。第二，概念同源：脚本元数据里的 @match 对应扩展 manifest 里的 match patterns，GM_addStyle 对应注入 CSS，GM_setValue 对应 chrome.storage，学一遍两边通用。第三，试错便宜：想法不成熟时先写脚本验证，验证通过再升级成正式扩展上架，沉没成本最低。

写脚本时正则是高频工具——URL 匹配、文本替换、选择器过滤都离不开它。正则匹配写法可参考本站《正则表达式从入门到精通》：正则实战。

工具链方面，油猴自带编辑器够用，但复杂脚本建议在外部编辑器里写好再粘贴进去。如果你平时用 HBuilderX 做前端开发，它的代码补全和本地工程管理能让脚本开发舒服很多，技巧见 HBuilderX 效率技巧。

本章小结

Tampermonkey 是用户脚本的运行底座，Greasy Fork 等社区站是脚本的主要流通渠道；安装前读元数据、扫代码、看更新时间是基本安全素养。脚本与扩展能力相通、概念同源，是进入扩展开发最好的练手场。

官方文档不覆盖用户脚本领域，本章内容依据社区通用实践整理；涉及扩展 API 的部分，仍以 https://developer.chrome.com/docs/extensions 为准。

管理器的日常操作速查

装好之后，这几个操作会高频用到，先建立操作地图：

两个容易困惑的点提前说清。其一，脚本的 console 输出出现在目标网页的控制台，不是油猴面板——找日志要去页面 F12 里看。其二，同一个脚本不同浏览器里行为可能不同，因为 GM API 的实现由各家管理器决定，Tampermonkey 的实现最完整，跨浏览器分发脚本时要在多个管理器里实测。

逛脚本站的具体打法

搜索之外，Greasy Fork 还有几类值得定期翻的入口。每日/每周热门榜能看出社区的注意力在哪：某网站突然改版引发适配潮、某个新玩法爆发，榜单都是最先反映的地方。分类浏览适合顺藤摸瓜：找到一个好脚本后，看同作者的其他作品，作者风格与质量通常稳定。脚本的「反馈」区是隐藏金矿——评论区里的 bug 报告、适配请求、改进建议，比脚本本身更能教你「这类需求大家实际怎么用」。

关注更新日志的习惯也值得养成。老练的脚本作者会在版本说明里写清「适配了某站的改版」，读几个月你就对「网站改版会让哪些功能失效」有了手感，写自己的脚本时防御性会强很多。

脚本管理的工程习惯

脚本装多了（超过二三十个）就会出现管理问题，几个社区验证过的习惯：

1. 命名带前缀：自己的脚本统一加前缀（如 my-），与安装的社区脚本区分开，导出备份时一眼能认出哪些是自己写的；
2. 写 @description：三个月后回看，靠脚本名根本想不起它是干嘛的，描述里写清楚触发站点和功能；
3. 版本号递增：改一版加一版号，出问题能回退到确定的可用版本；
4. 定期导出：油猴的脚本存在浏览器 Profile 里，重装浏览器就没了，实用工具里的导出功能就是你的备份。

这些习惯成本低，但都是从「玩玩」走向「认真写」的分界线。管理器还会自动检查 @version 变化来拉取脚本更新，所以给社区脚本投稿时，版本号纪律直接影响别人能不能收到你的修复。

安全事件怎么看

用户脚本历史上有过投毒事件：热门脚本被接手后加入数据窃取代码，或脚本站出现仿冒的假脚本。防住的要点还是第一章说的那三条：读元数据看匹配范围、扫代码看跨域请求、看更新时间与作者信誉。多加一条：同名脚本比对作者主页，确认来源是原作者而不是仿冒者。脚本生态没有商店级审核，你的判断力就是审核。

本章小结

Tampermonkey 是用户脚本的运行底座，Greasy Fork 等社区站是脚本的主要流通渠道；安装前读元数据、扫代码、看更新时间是基本安全素养。脚本与扩展能力相通、概念同源，是进入扩展开发最好的练手场。

官方文档不覆盖用户脚本领域，本章内容依据社区通用实践整理；涉及扩展 API 的部分，仍以 https://developer.chrome.com/docs/extensions 为准。

脚本与扩展的「第一个对照实验」

趁热做个对照：把同一个功能（改页面背景）分别用脚本和扩展实现，感受两者的差异点在哪。脚本版只需 GM_addStyle 加一行；扩展版要 manifest 声明 content_scripts、写 CSS 文件、重载扩展。功能等价，但两版的行为细节不同：扩展的 CSS 在 DOM 构建前注入，无闪烁；脚本要配 @run-at document-start 才能达到同样效果。这个对照实验五分钟做完，却把「能力相通、机制不同」这句话变成了具体的手感——它也是你判断「这个需求该用哪条路」的直觉来源。

脚本生态与扩展生态的另一个差异是「口碑机制」：脚本站的评分与安装量公开透明，作者直接面对用户反馈；扩展商店多了审核这道闸，反馈链路更长。做开源产品的人两种链路都体验一遍，对「如何让用户信任你的代码」会有更立体的理解。

把这两个差异记在心里，后面读扩展章节时会不断与脚本时代的经验对表——每一次「原来扩展是这样处理的」都是理解加深的机会。

最后用两个代码片段收束本篇。第一段是脚本的最小骨架，可以直接当新脚本的起点：

// ==UserScript==
// @name     骨架模板
// @match    https://example.com/*
// @grant    none
// ==/UserScript==
(function () {
  "use strict";
  console.log("script ready:", location.href);
})();

第二段演示 GM 存储的最小读写，验证管理器的特权能力是否可用：

// ==UserScript==
// @match    https://example.com/*
// @grant    GM_setValue
// @grant    GM_getValue
// ==/UserScript==
GM_setValue("ping", Date.now());
console.log("storage ok:", GM_getValue("ping"));

两段都能跑通，说明你的环境完全就绪，第二章的正式内容可以放心开始。

本章由 WorkBuddy 原创整理，API 行为依据 Chrome 扩展官方文档（Manifest V3）。