我第一次打开 Greasy Fork 的脚本列表，说实话没什么特别的感觉。满屏的英文、奇怪的注释、参数列表，第一眼看上去离普通人太远了。但真正把一个用户脚本装进浏览器，跑起来之后，我才意识到过去自己花在网页重复操作上的时间有多冤枉。Greasy Fork 这个网站，核心就一件事：它给用户脚本提供了一个集中的托管、分发和更新入口。你可以在这里找到别人写好的脚本，一键装进浏览器，也可以把自己写的脚本传上去分享、维护。这篇内容我准备把 Greasy Fork 从是什么、怎么用、怎么选，到怎么自己写脚本、怎么安全避坑，完完整整讲一遍，适合那些每天重度依赖浏览器，又不想被重复操作拖住的人。
1. 为什么 Greasy Fork 值得被好好认识
1.1 先理顺名字和关系：它到底是个什么站
很多人第一次听说 Greasy Fork，是因为在搜索引擎里搜“油猴脚本”这个中文说法。油猴脚本这个称呼，其实是从早期的一款浏览器扩展“Greasemonkey”翻译过来的，Greasemonkey 的中文意思直译就是“油猴”。不过 Greasemonkey 早期只支持 Firefox，后来为了跨浏览器使用，大家开始用 Tampermonkey、Violentmonkey 这类脚本管理器，而 Greasy Fork 则是存放这些“用户脚本”的仓库站。简单说：脚本管理器是容器，Greasy Fork 是脚本市场，两者是配合关系，不是同一个东西。
这个站点的核心逻辑并不神秘。网站把脚本集中在一个页面上，每个脚本都配有作者、版本号、安装量、评分、更新时间和源码。用户浏览之后，点页面上的安装按钮，脚本管理器就会接管下载、安装和后续更新。所有脚本都是 JavaScript 代码，页面安装时实际上是安装了一个带特殊注释头的 JS 文件。这种“代码即应用”的模式，让脚本生态比普通浏览器扩展更轻更快，也让 Greasy Fork 成为目前比较活跃的用户脚本托管地之一。
1.2 它真正解决的核心问题：把“手动”变成“自动”
浏览器本身是一个很称职的“浏览器”，但它默认情况下相当被动。你打开同一个后台管理页面、点同一个按钮、复制同一段数据，这些事情每天重复十次，浏览器不会嫌烦，你自己会嫌烦。用户脚本的意义就在于，允许你把“每次都要做一遍”的操作，写进一段脚本里，让页面加载后自动执行。
我在实际使用中最大的感受是：脚本解决的往往不是那种惊天动地的功能，而是极其琐碎的重复动作。比如某个后台页面每次都要展开侧边栏才能看到统计数字，比如搜索结果页有很多固定的推荐区域干扰判断，再比如某个文档站复制代码时自动多了一串版权尾巴。这些单次只需要两秒钟的操作，乘以一天几十次，就会变成负担。脚本就是把这些负担抹平的工具，Greasy Fork 则是让这类工具能被人发现、安装、迭代的平台。
1.3 适合谁，不适合谁
如果你只是偶尔用浏览器查查资料，不太需要脚本，安装管理器反而增加理解成本。但如果你是下面几类人，Greasy Fork 值得花一个下午研究：
- 工作里依赖网页后台，每天有大量表单填写、状态切换、信息核对的人
- 喜欢在浏览器上折腾生产力工具的前端、产品、运营和数据分析师
- 经常做网页信息收集，需要导出、整理、格式化内容的人
- 对网页体验有执念，想给网站修掉某些“不合理默认行为”的人
我个人的建议是：不用急着把所有网页都脚本化，先从一个真正让你烦躁的重复操作开始，体验一次“页面自己帮你干活”的感觉，后面自然会明白哪些场景值得投入。
2. 用户脚本和浏览器扩展的底层差异，决定了你用它的方式
2.1 用户脚本在浏览器里到底干了什么
用户脚本本质上是一段 JavaScript，通过脚本管理器在指定页面加载时注入执行。它可以直接操作当前页面的 DOM（网页结构）、监听事件、修改样式、发起网络请求。由于它直接在页面的上下文里运行，所以能做得非常“贴近现场”的事情，比如把搜索结果里的某个DOM节点挪个位置、给网页按钮绑定新的点击事件、把页面中的数据抽出来重新组装。
从浏览器的视角看，脚本管理器的角色更像一个“中转站”。它读取脚本里的匹配规则，决定哪些网站需要注入哪些代码。这个过程不需要重新打包浏览器扩展，不需要等待商店审核，改完核心代码之后，管理器检测到脚本更新，就会自动拉取新版本。这种机制带来的直接好处是：迭代速度极快，一个问题从发现到修复，往往以小时计，而不是以商店审核周期计。
2.2 脚本和扩展的关键差异
很多人会问：浏览器扩展不是也能干这些事吗，为什么还要用脚本？我用下面的表格来对比一下：
| 对比维度 | 浏览器扩展 | 用户脚本 |
|---|---|---|
| 形态 | 打包完整的扩展应用，包含 manifest、图标、后台页面 | 一段带注释头的 JavaScript 文件 |
| 安装途径 | 通过浏览器应用商店上架 | 通过脚本管理器安装，Greasy Fork 这类托管站分发 |
| 权限模型 | 声明式权限列表，权限和使用场景绑定 | 通过 @match、@grant 等字段声明注入范围与 API 权限 |
| 开发门槛 | 需要了解扩展 API、打包发布流程 | 懂 DOM 操作和一点 JavaScript 就能上手 |
| 更新速度 | 需要按商店流程重新审核 | 脚本更新后管理器自动同步，基本无审核等待 |
| 对页面侵入性 | 使用 content script，隔离程度高 | 直接在当前页面运行，操作更直接，但需要自己注意作用域 |
我的经验是，两者不是替代关系，而是各有利弊。扩展胜在稳定和权限结构清晰，适合做长期、复杂、跨页面的功能；脚本胜在轻量和灵活，适合针对特定网站做个性化增强。你完全可以在浏览器里同时用几个扩展，再配几个脚本，各管一摊。但如果你只是想让某个页面好用一点，专门去写一个扩展确实有点杀鸡用牛刀，脚本显然更合适。
2.3 搞懂几个元数据字段，接下来才看得懂脚本
在 Greasy Fork 上点开任意一个脚本，第一眼看到的就是头部注释，也就是元数据。对于普通用户，你不需要读懂全部，但至少要认识这几个关键字段：
- @name：脚本名称，没什么好说的
- @namespace：脚本的命名空间，一般用来区分同名脚本，最好填一个独立标识
- @version：版本号，脚本更新靠它判断
- @match：匹配的网页地址模式，只有匹配到的页面才会注入脚本
- @grant：授权调用的 GM API，比如 GM_setClipboard 表示可以访问剪贴板
- @run-at：脚本注入的时机，比如 document-start 和 document-end
对于一个使用脚本的人来说，@match 和 @grant 是最值得关注的两个字段。@match 决定了脚本的作用范围，如果你在淘宝商品页装了一个脚本，结果它的 @match 是 https:///，那就要警惕它是否在别的页面也会生效。@grant 则反映了脚本要用多少“额外权限”，有些脚本只操作 DOM，grant none 就够了，没必要申请一堆 GM API。
3. 从零到用上第一个脚本的完整路径
3.1 先装一个脚本管理器
Greasy Fork 上的脚本不会凭空跑到浏览器里，你要先安装一个用户脚本管理器。目前最常用的三个是 Tampermonkey、Violentmonkey 和 Greasemonkey。我的建议是：Chrome 系浏览器选 Tampermonkey，Firefox 系浏览器选 Tampermonkey 或者 Violentmonkey 都行。Greasemonkey 现在已经相对少用了，新手不必从它开始。
安装管理器没什么特殊之处，在浏览器自带的扩展商店里搜索对应的名字，找到官方发布的那一个，添加到浏览器即可。装好后，浏览器工具栏会出现一个管理器的图标，点击它能进入管理面板，看到已安装脚本、更新情况、运行日志和设置项。
一个很容易被忽略的点是：脚本管理器本身也是扩展形式存在，但它并不像普通扩展那样直接给网页加按钮或改样式，它只提供“运行用户脚本”的环境。真正干活的，是你在 Greasy Fork 上安装的那些脚本。
3.2 在 Greasy Fork 上找脚本并安装
打开 Greasy Fork 之后，页面有搜索框，也有分类和热门脚本列表。如果你要找特定网站的脚本，直接搜网站名加空格加功能关键词，比如“某网站 导出”或者“某网站 增强”。搜索结果的排序默认会综合考虑安装量、评分和更新时间，我建议你在排序时重点关注最近更新时间和脚本版本，一个长期没更新的脚本往往意味着它很可能已经失效。
确定一个脚本后，点进去先别急着安装。花两分钟看四样东西：
- 脚本的总安装数和近30天更新频率，数据太难看就要留心
- 用户评分和评论，尤其是有没有最近“不好用”“失效了”的反馈
- 版本号和最后更新时间，和网站功能的变动周期对照一下
- @match 字段，确认作用范围符合预期
看完之后，点击页面右上角或侧边的“安装此脚本”绿色按钮，管理器会弹出一个确认窗口，里面会再次列出脚本名称、匹配范围、授权项。确认无误后点击安装，脚本就进入管理器了。之后只要你访问匹配的网站，脚本就会自动运行，不需要每次手动操作。
3.3 脚本的管理、更新与失效处理
装好脚本后，在管理器面板里可以随时启用、禁用、删除。我建议你按网站维度管理脚本，一个网站尽量只保留你真正需要的两三个，不然容易互相冲突。禁用和删除的最大区别是：禁用只是暂时不执行，删除则会被管理器从本地移除，但下次你在 Greasy Fork 上还能重新安装，所以大胆删没事。
脚本更新是自动发生的，管理器默认会定期检查 Greasy Fork 上的版本。更新前管理器会提示新版本的改动内容，尤其要留意它是否扩大了 @match 范围、增加了 @grant 权限。有些脚本作者会在更新说明里写清楚改动，有些写得比较模糊，这种情况下我通常会先去 Greasy Fork 看看最近评论再决定是否更新。
脚本失效是绕不过去的问题。网站改版是最常见的失效原因，页面结构一变，原来的选择器匹配不到元素，脚本就静默失败了。遇到这种情况，你可以先看看 Greasy Fork 评论里有没有人反馈，有的话等作者更新；没有的话，可能需要自己学着改代码，这也是我后来决定认真学写脚本的第一推动力。
4. 实测下来最值得脚本化的几个场景
4.1 页面增强与阅读优化：用最少的代码做最有体感的事
我最早接触用户脚本，是因为一个让我崩溃的阅读体验：某个技术文档站文章内容很窄，两侧大片留白，图片还要点击才能看大图。用脚本把正文容器的最大宽度调大、图片加一个点击放大按钮之后，阅读体验好了非常多。这种脚本通常只有几十行代码，不需要网络请求，也不申请高级权限，只是改改样式和绑定事件，属于最安全的范畴。
类似这么改动的常见做法包括：把页面的默认字体调成你更喜欢的中文字体，去除页面上固定的悬浮广告位，给深色背景的页面强制套一层护眼滤镜，甚至只是把某个按钮固定在页面底部方便点击。你在 Greasy Fork 上搜“主题”或“样式”这类关键词，能发现大量这种小而美的脚本。
4.2 信息导出与工作流自动化：真正值回时间投入的地方
页面增强只是表面功夫，用户脚本真正值钱的地方在于能帮你处理信息流。比如你每天要整理网页数据到表格里，手动复制粘贴相当痛苦。用户脚本可以读取当前页面里的表格、列表或结构化数据，把它们转换成 CSV 或 Markdown，再通过剪贴板写出。这个流程从“打开网页、框选、复制、到表格里粘贴整理”变成“点一下按钮、直接粘贴”，省下的不只是时间，还有出错的概率。
工作流自动化就更简单粗暴了。比如后台系统里每天要重复录入的信息，脚本可以预填充默认值；一个多步骤操作，脚本可以自动完成前几步，留你确认最后一步。这里我想特别强调一句：自动化的价值在于把重复但必须有人的确认环节留给人，而不是全流程无人化。把最后一步留给你自己，能避免很多因为批量操作带来的不可逆后果。
4.3 注意过度脚本化：脚本不是越多越好
我为不少网站装过脚本，装到最后发现痛苦的源头不是网站难用，而是脚本互相打架。两个脚本都在页面里插入浮动按钮，结果一个把另一个盖住了；两个脚本都监听同一个快捷键，结果一个触发了另一个也触发。这种事情调试起来并不轻松。
所以我的经验是：每个网站在同一时间只保留一个主力脚本。如果发现一个脚本的功能覆盖了另一个，果断卸载功能较弱的那一个。脚本化应该是一个持续做减法的过程，而不是不断地加。你要的是一个能稳定帮你干活的半自动助手，不是一个时不时捣乱的小孩。
5. 脚本安全与授权边界：不为方便牺牲安全
5.1 Greasy Fork 的审核机制与它的局限性
不少人对 Greasy Fork 有个误解，以为上面的脚本都经过了官方的严格安全审核，所以可以直接安装。实际上 Greasy Fork 有基本的内容审核和社区反馈机制，但脚本毕竟是代码，托管平台很难做到逐行审查，也不可能对每个脚本的真实行为负责。它更像一个社区，靠的是作者的自觉、使用者的反馈和评分机制来维持总体质量。
这套机制决定了两个事实：第一，绝大多数主流脚本是透明公开的，很多人盯着源码，恶意脚本很难长期藏住；第二，仍然存在一定的风险，尤其是那些安装量小、来源不明、授权范围很大的脚本。所以你不能把安全判断完全交给平台，自己也得会看几眼。
5.2 安装前，先审查 @match 和 @grant
看脚本源码对普通用户可能有点门槛，但看元数据几乎是零门槛。装任何脚本之前，打开管理器的详情面板或者 Greasy Fork 的代码页，确认两件事：
- @match 是否具体到目标网站。比如脚本是针对“某网站的结果页”写的，那么 @match 应该是 https://example.com/results/，而不是 https://example.com/，更不是 https:///
- @grant 是否申请了不必要的能力。如果脚本只是改页面样式，却申请了 GM_xmlhttpRequest（跨域请求），你就要多问一句为什么
我把一些值得警惕的信号整理成了一份快速检查列表：
| 风险信号 | 解释 |
|---|---|
| @match 使用 https:///或 http:/// | 脚本会在几乎所有网站运行，需要特别谨慎 |
| @grant 申请了 GM_xmlhttpRequest | 可以跨域发送请求，可能把当前页面数据回传到其他服务器 |
| @require 引用了外部 JS 文件 | 脚本主体之外还有一段外部代码，审核风险变高 |
| 代码中存在明显的账号、密码、Token 相关字符串 | 有潜在的信息收集行为 |
| 评论中存在“账号异常”“收到验证码”等反馈 | 可能是大量用户共同遭遇的问题信号 |
5.3 运行中的观察：装完不等于万事大吉
即使安装前检查过，安装后也要留个心眼。一个新的用户脚本首次运行时，我会特别留意页面上发生了什么变化、有没有多出不明请求、账号状态有没有异常。一些恶意脚本会延迟触发，比如安装几天后才开始有异常行为，所以不要因为“刚装完没事”就彻底放松。
还有个容易被忽略的坑：同一个脚本可能在某次更新后被插入了恶意代码。Greasy Fork 上有不少脚本是多人维护或多作者 fork 的，某个分支的新版本和旧版本行为可能并不一致。更新前我习惯于对比一下版本号，如果脚本从 1.0 跳到 2.0，改动通常很大，那更要看评论和源码。
5.4 权限最小化：给自己立一条使用规则
我一直坚持一条规则：再方便的工具，也不值得拿自己在网页端的隐私和账号安全去换。脚本的权限最小化原则其实很简单——能只作用在一个网站，就不要让它作用到全网；能只读取页面元素，就不要给它跨域请求的权限；能用浏览器原生能力解决，就不要用 GM API。
事实上 Greasy Fork 上很多有价值的脚本都是非常克制的，作者会在元数据里把 @grant 设置成 none 或者只申请最小权限，并且在脚本介绍里说明自己的数据使用情况。这种脚本用起来最放心。相反，如果一个脚本明明没必要申请很多权限，却偏偏大幅声明，不管它宣传的体验有多好，我都建议你换一个替代品。
6. 自己动手写第一个用户脚本，并发布到 Greasy Fork
6.1 用户脚本的基本骨架：一段注释头加一段执行代码
当你用脚本次数多起来，总会遇到一个“改一点点就完美”的需求，这时候自己动手是很好的选择。用户脚本的结构非常简单，最外层是一个 JS 文件，文件开头的注释块声明元数据，注释之后是实际运行的代码。
一个最基础的脚本骨架长这样：
// ==UserScript== // @name 我的第一个脚本 // @namespace com.example.my-script // @version 0.1 // @description 这是一个示例脚本 // @match https://example.com/* // @grant none // @run-at document-end // ==/UserScript== (function () { 'use strict'; // 这里写你要执行的代码 console.log('脚本已启动'); })();这个骨架最重要的事情有两个：一是 @match 必须写对，二是整个执行逻辑最好包在一个 IIFE（立即执行函数）里，避免污染页面自带的全局变量。哪怕你只是初学 JavaScript，也可以把这段结构当模板保存，以后每次新建脚本都从它开始改。
6.2 一个可以立刻上手的例子：页面标题复制按钮
我拿一个实际做过的小脚本做例子。当时我有一个使用场景：每天要反复打开一些项目文档，记录文档标题和链接地址。手动复制标题再复制链接，两步操作说不上累，但是架不住次数多。于是我用脚本在页面右上角放了一个按钮，点击一次就把“标题 + 空格 + 链接”复制到剪贴板。
实现代码大致如下：
// ==UserScript== // @name 一键复制页面标题 // @namespace com.example.copy-title // @version 0.1 // @description 在页面右侧添加一个按钮，点击复制标题和链接 // @match https://*/* // @grant none // @run-at document-end // ==/UserScript== (function () { 'use strict'; const button = document.createElement('button'); button.textContent = '复制标题'; button.style.position = 'fixed'; button.style.top = '80px'; button.style.right = '12px'; button.style.zIndex = '99999'; button.style.padding = '4px 10px'; button.style.cursor = 'pointer'; button.addEventListener('click', function () { const text = document.title + ' - ' + location.href; const textarea = document.createElement('textarea'); textarea.value = text; document.body.appendChild(textarea); textarea.select(); document.execCommand('copy'); document.body.removeChild(textarea); button.textContent = '已复制'; setTimeout(function () { button.textContent = '复制标题'; }, 1500); }); document.body.appendChild(button); })();这个脚本不长，但你能从中理解用户脚本最常见的套路：创建 DOM 元素、绑定事件、修改页面内容、利用原生 API 完成操作。浏览器 API 在这里和普通网页开发几乎一致，区别只在于脚本可以附加到任何匹配的页面上。
6.3 调试脚本的三板斧
写完脚本后，最常遇到的是两种情况：脚本没起作用，或者起作用的时机不对。我先说调试的基本思路。
第一步：先确认 @match 和 @run-at。我踩过最多的坑就是 @match 写得太严格，比如目标网站实际域名带了二级前缀，而我写的匹配规则没包含，脚本自然不运行。第二步：打开浏览器开发者工具的 console 面板，看有没有报错。用户脚本报错信息通常会带上脚本文件名，沿着堆栈信息能很快定位到问题行。第三步：在脚本里手动加 console.log 输出关键变量，确认你的选择器是否真能选中目标元素，比如 document.querySelector 返回的值是不是 null。
一个很实际的建议：不要一开始写长脚本，先写一个只有 console.log 的最小版本，确认注入成功；再逐步添加 DOM 操作，确认元素能找到；最后再加事件、逻辑、异步处理。小步小步地验证，远比一次写完再面对一堆错误高效。
6.4 发布到 Greasy Fork 和维护时需要注意的细节
脚本在本地测试通过之后，就可以考虑发布到 Greasy Fork 上，让更多人使用。发布时要填几项基础信息：脚本名称、描述、主页地址、支持的语言和许可证。描述不要只写“优化网站体验”，尽量说清楚这个脚本解决了什么问题、影响哪些页面，这样搜索匹配更准确，也能减少用户安装后的预期落差。
发布之后，脚本的维护才是重点。网站改版后脚本失效，是最常见的反馈来源。你在脚本里用越具体的选择器，失效概率越大；用越语义化的选择器（比如根据 data 属性、模块类名判断），抗改版能力越强。前期写代码时稍微注意一点，能减少很多后期的更新频率。
另外，发布到 Greasy Fork 的脚本默认是公开的，其他人可以提问题、反馈 bug，也可能 fork 你的代码做改进。这是社区运作的正常方式，不必敌视，反而要善用反馈。合理地回复评论、保持版本更新频率、在代码里写清楚改动记录，这些看起来不起眼的动作，决定了你的脚本能不能被更多人信任。
回看我这些年用脚本和写脚本的经历，最大的收获倒不是省了多少时间，而是学会了一种思路：任何重复出现的网页操作，都有被自动化的可能。Greasy Fork 的价值，正在于它把这股力量开放给了所有人，你不需要成为编程高手，只需要会找、会装、会辨别，就能享受脚本生态带来的便利。如果你还在犹豫从哪里开始，我建议先找一个烦躁了两周以上的网站操作，去 Greasy Fork 搜一下，装一个无权限或极低权限的脚本试试看，大概率会打开一扇新大门。
