Dev Server 代理、系统级抓包代理、API 客户端、改请求头的扩展、直接改应用自己的配置——跨环境联调这五种做法都是真实可行的答案。它们的差别落在四个具体成本上：你要改动什么、能保留多久、刷新页面后还在不在、以及流量要走到哪一层这个工具才看不见。本页就把这四个代价摆清楚，并且直说浏览器规则在哪些情况下是错的选择。
一句话版本：如果请求由你正打开的某个页面发出，而你不改这个页面的代码就想让它被另一个环境应答，浏览器里的一条规则是最短路径——因为请求由扩展发出，页面的
Access-Control-Allow-Origin
校验根本不会执行。如果流量不是来自浏览器页面，请改用系统级抓包代理。
| 你的场景 | 代价最低的正确解法 | 原因 |
|---|---|---|
| FAT 上的页面要调 UAT，而后端不归你改 | 浏览器规则 | 不用重新部署、不用提网关工单，一次覆盖浏览器里的所有项目 |
本地 Dev Server 需要把 /api 转发给后端，且全团队都要这样 |
Dev Server 代理 | 配置在仓库里，能被提交、被 review，同事拿到的是同一份 |
| 需要看到或修改手机 App、桌面程序、服务端进程的流量 | 系统级抓包代理 | 它工作在操作系统或网络层；浏览器扩展只能看到浏览器的页面 |
| 接口还不存在，你需要和后端同学先约定它的形状 | API 客户端 | 在那里请求是可共享的产物；浏览器规则只活在你自己的 Chrome 配置里 |
| 线上页面只需要加或换一个请求头 | 改请求头的扩展 | 最小改动配最小工具——直到你还需要换域名 |
| 这个环境差异是产品长期行为 | 应用配置 | 由源码保证正确，胜过一条只存在于你机器上的规则 |
最后一行比第一行更重要。浏览器规则是一台调试仪器：它是看清某个行为最快的方式，但不是安置一个决定的地方。一旦「这个页面连这个域名」变成固定要求，请把它搬回应用的配置里。
每一条都先讲这个做法真正擅长什么。只列类别：同一类别内部能力差异很大，请以你实际在用的工具为准逐项核实。
是什么。构建工具里的一张代理表——Vite、webpack-dev-server 之类把
/api 转发到另一个源，于是浏览器只看到一个源，CORS 根本不会进入对话。
真正擅长什么。它在仓库里，能被提交、能被评审，全团队一致；不需要装扩展；是一个项目本地开发的正确默认值。
到哪一步失效。它按项目、按 Dev Server 生效：换一个仓库就要重新配一遍并重启。它只看到发往这台 Dev Server 的流量，页面直连第二个域名时它管不到。而且它只转发——不改写响应、不 Mock 一个还不存在的接口、也不能按需注入延迟。
与浏览器规则的关系。互补。项目日常开发继续用仓库里那张代理表；只属于你个人的跨环境场景交给浏览器规则。
是什么。本机上的一个进程，操作系统或浏览器被设置为经由它出口（这一类别里的开源参照是 mitmproxy）。要读取 HTTPS，它必须成为客户端信任的证书颁发机构。
真正擅长什么。覆盖范围无人能敌：浏览器、手机 App、桌面程序、服务端进程全在一处，请求响应可完整检视，能打断点、能脚本化、能存成会话文件。
到哪一步失效。安装成本就是答案。装一个受信任的根证书会改变你机器的安全态势，部分客户端做了证书 pinning，公司电脑上还可能要走审批。它是系统级的：你停止调试之后它仍在拦截，这类工具常常是你还没信过结果就已经关掉了。
与浏览器规则的关系。浏览器规则做不到系统级流量，它也不假装能做。它放弃了这个覆盖范围，换来的是不需要装证书、不动系统设置、也没有「离开浏览器后记得关」这件事。
是什么。一个独立工具：手工搭一个请求、发出去、读响应，配集合、环境与 Mock 服务。
真正擅长什么。契约工作。和后端同学一起设计并确认接口形状，维护一份可共享的请求库，在没有任何 UI 的情况下验证一个接口。
到哪一步失效。响应到达的是客户端，不是你的应用代码。于是 UI 分支、axios 拦截器、错误处理、重试逻辑全都未被验证。页面拿到载荷之后做的事——cookie、重定向、同源凭据、流式读取——都在客户端能证明的范围之外。
与浏览器规则的关系。按顺序配合最好。在客户端里设计好 Mock，把同一份响应体贴进规则的 Mock 响应，让真实页面去消费它。这个组合补上了两边单独都补不了的缺口。
是什么。轻量的浏览器扩展，按 URL 模式重写请求头或响应头——底层常常就是声明式请求重定向 API。
真正擅长什么。一次性的头部改动：accept-language、覆盖 cache-control、加个调试开关。概念少，立刻生效。
到哪一步失效。请求头就是它的全部作用面。它通常不替换请求体、不能返回你自定义的 Mock 响应、没有单请求延迟或重试，也碰不到 WebSocket 连接。
与浏览器规则的关系。本扩展对「只重写 URL」的那部分规则用的是同一套网络层机制，规则一旦需要改请求头、请求体或响应，再叠加后台服务线程通道。所以实践上是它的超集，代价是要学的东西更多。
是什么。最诚实的做法：改 base URL、改环境文件、改源码里的 token，重新构建，让应用直连另一个环境。
真正擅长什么。对所有人可复现，能在 CI 里跑，机器重装之后还在。差异是长期存在时，就该放在这里。
到哪一步失效。每次尝试一个构建循环，一处必须记得回滚的 diff，还有一个绕不开的 CORS 问题——页面现在调的是外部域名，后端必须放行，于是变成一次网关改动加一次重新部署。
与浏览器规则的关系。规则就是同一次编辑的临时版本，只不过发生在源码树之外。对请求的效果相同，评审时没有忘回滚的风险。
绿色对该行是有利，橙色是部分具备，灰色是不具备。列是类别，所以每个格子请读作「该类别通常如此」，而不是对某个具体产品的断言。
| 做法 | 本扩展 | Dev Server 代理 | 系统级抓包代理 | API 客户端 | 改请求头的扩展 | 改应用配置 |
|---|---|---|---|---|---|---|
| 需要后端或网关配合改动 | 不需要 | 常需要，为 CORS | 不需要 | 不需要 | 不需要 | 不需要 |
| 按项目逐个配置 | 否——全浏览器生效 | 是 | 系统级 | 按集合 | 按规则集 | 是 |
| 刷新页面后不用重做 | 是 | 是 | 是 | 不适用 | 是 | 到你回滚为止 |
| 改写响应（状态码、响应头、JSON 字段） | 是 | 否 | 是 | Mock 服务，非真实页面 | 仅响应头 | 否 |
| 在界面上做 Mock / 延迟 / 阻断 / 重试 | 是，含条件化 Mock | 需额外插件 | 是 | 是 | 通常只有 Mock | 否 |
| 覆盖 WebSocket 流量 | 是 | 少见 | 是 | 否 | 否 | 看应用实现 |
| 读取 HTTPS 需要本机 CA 证书 | 不需要——跑在浏览器内 | 不需要 | 需要 | 不需要 | 不需要 | 不需要 |
| 覆盖非浏览器流量（手机、桌面、服务端） | 不能——只在浏览器内 | 不能 | 能 | 只覆盖它自己发出的请求 | 不能 | 视情况 |
| 能作为受评审的产物分享给团队 | 导出 JSON 入库 | 能——就在仓库里 | 会话文件 | 能——集合 | 常带云端同步 | 能——就在仓库里 |
| 无需浏览器配置即可在 CI 中工作 | 否 | 是 | 是 | 是——CLI runner | 否 | 是 |
请把最后两行当作诚实的边界。本扩展在系统覆盖范围和团队可复现性上是输的；它赢在决定日常调试效率的两件事上：浏览器之外什么都不用改，以及刷新之后规则还在。
一份只列优点的对比是广告。下面是你应该另请高明的场景。
服务间调用、手机 App、桌面进程、脚本里的
curl——它们都不会注入内容脚本。请用系统级抓包代理，或者在基础设施层把路由改对。
规则存在你的 Chrome 配置里。如果这个行为属于项目，它就应该属于仓库：一条 Dev Server 代理配置，或者一个应用配置项。你可以导出 JSON 给同事导入，但那是交接，不是事实来源。
浏览器扩展的规则集没有 headless 模式。自动化测试应当直连后端，或者跑在流水线里配好的代理之后。
chrome:// 页面、Chrome
应用商店以及其他扩展的页面都不能注入内容脚本，拦截通道在那里跑不起来。网络层重定向规则对这些页面发出的请求依然生效。
如果一条规则只重写 URL，浏览器执行的是重定向，仍会校验重定向后响应的
Access-Control-Allow-Origin。给这条规则加上任意一项能力——改响应头是最便宜的一种——它就会切到由扩展发出请求的那条通道。
采用某些缓存策略的 service worker，以及已经走系统代理的流量，可能不会按你期待的方式被拦截。相信一个「没命中」的结论之前，先用 URL 匹配测试确认一次。
把你原本转发的 /api 前缀写成一条通配符规则：https://fat-api.example.com/* →
https://uat-api.example.com。仓库里那张代理表不要动——其他开发者和 CI 还依赖它。
把重写规则照搬成一条浏览器规则，抓包代理继续留给它更擅长的：非浏览器客户端与深度检视。验证规则时先关掉系统代理路由，否则两层会抢同一个请求。
把 Mock 响应体连同你们约定好的状态码与 content type 一起贴进规则的 Mock 响应。导入真实流量的 HAR 导出可以自动成规则，通常比重敲一遍快。
把 token 从代码里挪进规则的请求头覆盖，然后回滚源码改动。这个值不再出现在 diff 里，关掉规则就是完整的回滚。
产品自身的 FAQ——能力边界、隐私、权限、两条通道如何工作——在 产品介绍页。这里的回答只关于「在这几种做法之间怎么选」。
对浏览器里的页面通常可以，而且在一个方向上更宽：一套规则覆盖浏览器里的所有项目，不必每个项目维护一张代理表；它还能改写响应，而不只是转发。但它替代不了非浏览器客户端、CI，以及任何不走 Chrome 的请求，那些场景仍需要 Dev Server 代理。
当流量不是来自浏览器页面的时候。服务间调用、经开发机代理的手机 App、桌面程序，以及需要沉淀成共享会话文件的场景，都属于系统级代理。它读取 HTTPS 的前提是充当客户端信任的证书颁发机构，而这正是浏览器内扩展省掉的那笔安装成本。
API 客户端能证明接口行为正确，证明不了你的页面能正确处理它。响应到达的是客户端而不是应用代码，于是 UI 分支、拦截器、错误处理全都未被验证。合适的用法是在客户端里设计好 Mock，再把同一份响应体放进浏览器规则，让真实页面去消费它。
改头类扩展在浏览器内重写请求头或响应头，这是整个问题里最小的一片。它们一般不把请求重定向到另一个域名、不替换请求体、无法返回一份自定义的完整 Mock 响应，也不处理 WebSocket——而恰恰是「重定向到另一个域名」这一步，让你不需要后端改 CORS。
可以，而且通常就应该这样。本地构建工具需要的项目继续保留 Dev Server 代理，非浏览器流量继续交给抓包代理，日常那种“这个页面应该连那个环境”交给浏览器规则。唯一要避开的是两条规则同时改写同一个请求，那会让结果难以推理。
