Header Editor 第三方规则使用指南：导入、安全校验与规则提交

• 开发工具
• 网络

导读

Header Editor 本身并不内置具体功能，它提供的是"管理与编写规则"的能力——所有请求/响应头修改、重定向、取消请求等行为，都由你编写的规则驱动。为了降低从零写规则的门槛，社区维护者会公开分享现成的规则集，官方文档（docs/docs/zh-TW/guide/third-party-rules.md、docs/docs/zh-CN/guide/third-party-rules.md）专门收录了一批第三方维护的规则清单。本文以这份清单为骨架，结合仓库源码深入讲解：第三方规则如何导入、规则 JSON 的内部结构是什么、导入时有哪些安全风险需要人工把关，以及规则维护者如何把自己的规则提交进官方列表。读完本文，你将能够安全、高效地使用和发布 Header Editor 第三方规则。

一、官方收录的第三方规则清单

当前官方文档在"第三方规则"页面维护了一张清单，收录了三个社区维护的规则集，每个规则集都标注了下载来源、作者与简介：

这些规则集以.json文件形式分发，作者在其个人仓库（GitHub 仓库或 Wiki 页面）维护更新，官方页面仅提供入口而不托管文件本体。也就是说，规则集的时效性与安全性完全取决于作者，这一点在官方文档开头就有明确声明（详见下文"注意"一节）。

二、使用第三方规则前的"注意"事项

官方文档在清单之前专门列出免责声明，这是使用第三方规则的第一原则：

• 清单中的规则由第三方维护，Header Editor不保证规则的时效性与安全性；
• 若导入的规则出现问题（如误拦截、重定向失效、行为异常），请直接联系规则维护者，而不是向 Header Editor 提交 issue。

这条声明非常重要：第三方规则本质上是"外部代码"（尤其是含自定义函数的规则），导入前需要用户自行判断其可信度。下文第五节将给出源码层面的安全校验要点。

三、第三方规则 JSON 的内部结构

要理解导入行为，先要弄清规则文件长什么样。从源码看，Header Editor 的规则按四张表组织，定义在 src/share/core/constant.ts：

TABLE_NAMES: request | sendHeader | receiveHeader | receiveBody

分别对应"取消/重定向请求类规则"、"修改请求头规则"、"修改响应头规则"、"修改响应体规则"。一个合法的第三方规则 JSON 就是这四个键与规则数组的映射，例如：

{ "sendHeader": [ { "name": "反盗链-百度图片", "ruleType": "modifySendHeader", "matchType": "prefix", "pattern": "http://imgsrc.baidu.com/", "action": { "name": "Referer", "value": "http://tieba.baidu.com" }, "enable": true } ] }

其中ruleType的可取值在 constant.ts 中定义：

导入时，程序会按这四张表逐条读取并解析，具体见 src/pages/options/components/import-drawer.tsx 中的TABLE_NAMES_ARR.forEach循环。旧版本规则（使用type字段而非matchType）也会被自动升级兼容，见 src/share/core/rule-utils.ts 的upgradeRuleFormat。

四、导入第三方规则的完整操作流程

官方文档列出的规则集均可在浏览器扩展的"选项 → 导入导出"界面中导入，源码实现位于 src/pages/options/sections/import-and-export/。具体流程如下：

4.1 选择"本地文件"导入

在选项页的"导入导出"区域，找到"本地文件"卡片（local-file.tsx）：

• 点击导入按钮，会弹出文件选择框（accept限定为.json，见 src/share/pages/file.ts）；
• 选中下载好的第三方规则 JSON（如CingList.json），程序以 UTF-8 读取文件内容并JSON.parse；
• 解析失败时会在 Toast 中直接提示错误信息。

4.2 逐条确认导入动作

导入抽屉（import-drawer.tsx）会以表格形式列出文件中解析出的每一条规则，并自动与现有规则按名称比对：

• 若本地已存在同名规则，会提示可"覆盖"；
• 每条规则提供三种动作：导入为新规则、覆盖已有规则、跳过不导入；
• 可勾选"保存到"推荐分组，或手动为全部规则指定分组；
• 点击"保存"后逐条调用Api.saveRule完成写入。

4.3 导入后的验证

导入完成并不代表规则一定生效，建议按 rule.md 中的说明做两项验证：

1. 在规则编辑页的"测试"表单里输入目标 URL，确认匹配结果符合预期（测试组件见 src/pages/options/sections/rules/edit/form-content/test.tsx）；
2. 直接访问规则目标站点，观察请求头/重定向行为是否符合规则设计意图。注意：开发者工具（Chrome 与 Firefox）不会显示被修改后的响应头，应以实际页面行为为准（详见 FAQ.md）。

五、安全校验：导入前必须做的源码级检查

官方文档反复强调"不保证安全性"，从源码看主要有两个风险点：

5.1 自定义函数 = 任意代码执行

规则若带有自定义函数（isFunction: true），在 Web Request 模式下会被编译为可执行函数。源码 src/share/core/rule-utils.ts 中：

if (initd.isFunction && ENABLE_EVAL) { initd._func = new Function('val', 'detail', 'util', initd.code); }

即code字段中的字符串会被new Function直接执行——等同于任意代码权限。导入含自定义函数的规则时，导入抽屉会弹出红色警告弹窗要求二次确认（见 import-drawer.tsx）。因此，导入第三方 JSON 前务必用编辑器查看其中是否含isFunction/code字段，且只信任可信作者的规则。

5.2 导出格式会剥离运行时字段

与之相对，官方导出的规则文件是"干净"的：createExport与convertToBasicRule会移除_re2、_reg、_filter_reg、_func、_v_key、_runner、_exclude以及id等运行时内部字段（见 src/share/core/rule-utils.ts）。如果你从非官方来源拿到带下划线前缀字段的 JSON，说明它可能不是标准导出产物，需格外谨慎。

六、第三方规则本身能做什么（典型场景）

虽然不能替第三方规则作者背书，但结合 rule.md 的常见示例，可以判断清单中规则集的典型价值：

• 防盗链/反防盗链：通过修改Referer请求头，解决图片等资源被站外引用拦截的问题（CingList.json 的典型场景）；
• 重定向：把 Google 公共库、Google 资源等请求重定向到可访问的镜像（HE-GoogleRedirect.json 的典型场景），正则匹配还支持$1占位符回填捕获组；
• 行为类规则：如禁用 AI 搜索、修改特定站点行为等（Willie169-HE.json 的典型场景）。

这些规则本质上是 JSON 配置，导入后同样遵循 Header Editor 的通用运行机制：DNR 模式性能更好，但 Web Request 模式功能更全面（支持自定义函数、正则排除），引擎会自动为每条规则选择运行模式（detectRunner，见 src/share/core/rule-utils.ts）。若规则涉及修改响应头/响应体，还需在选项中启用"修改响应体"功能，否则相关规则不会生效。

七、如何向官方提交你自己的第三方规则

如果你维护了一套规则集，希望被收录进官方清单，官方文档给出了明确渠道：通过 GitHub issue 提交，并使用专用的rule-submit-cn.md（中文）或rule-submit.md（英文）模板。提交时建议在 issue 中说明：

• 规则集的下载地址与作者信息；
• 规则集的功能简介（重定向、防盗链、安全增强等）；
• 规则的维护方式与更新频率，便于使用者评估时效性。

提交后由 Header Editor 维护者审核是否收录进 third-party-rules.md 列表。注意：被收录不等于官方背书，页面始终保留"由第三方维护、不保证时效性与安全性"的免责声明。

八、小结

第三方规则是 Header Editor 生态的重要组成部分，官方在 third-party-rules.md 中维护了一份小而精的清单（当前收录 CingList.json、HE-GoogleRedirect.json、Willie169-HE.json 三套规则）。使用它们的正确姿势是：先检查 JSON 中是否含自定义函数，再通过"导入导出 → 本地文件"逐条确认导入，最后用规则测试表单验证效果。官方还提供了 issue 提交流程，让更多维护者可以贡献自己的规则集。记住文档开头的提醒——规则出了问题，找作者，别找扩展。

• 开发工具
• 网络