Whistle 规则如何管理，团队协作时怎样避免配置冲突？

Whistle 的规则管理不要只理解成“谁在网页里改几行配置”。个人调试时，Web 界面足够快；团队协作时，真正麻烦的是规则来源、环境切换、命名规范和回滚机制。如果这些没有约定，今天 A 同学为了联调把接口代理到本地，明天 B 同学拉到同一份规则后就可能误连错环境。

规则应该放在哪里管理？

日常临时调试可以直接打开 http://127.0.0.1:8899/，在 Rules 面板里写规则并保存，适合验证某个接口、替换一个静态资源、临时 mock 一段响应。它的好处是所见即所得，Network 面板马上能看到命中情况；缺点是改动容易散落在个人机器上，别人不知道你改了什么。

团队长期使用时，建议把公共规则放到 Git 仓库，个人规则留在本地。公共规则只放稳定的域名代理、公共 mock、跨域头、常用环境入口；个人规则放本地端口、临时调试、风险较高的 host 覆盖。这样既能共享经验，也不会把每个人电脑上的实验配置带给全组。

bash
# 常用启动与检查
w2 start -p 8899
w2 status
w2 restart
w2 stop

# 如果需要指定规则文件启动
w2 start -f ./rules-dev

规则文件怎么组织更适合协作？

一份可维护的规则文件，应该先按业务或环境分组，再按命中范围从小到大排列。更具体的路径规则放在前面，宽泛的通配符和正则放在后面，否则容易出现“看起来写了规则，但一直没命中”的问题。注释不要写成流水账，最好说明这条规则解决什么问题、谁在使用、什么时候可以删除。

text
# user-service: 本地联调用户接口，owner: frontend-user
www.example.com/api/user host 127.0.0.1:3001

# mobile-h5: 移动端静态资源走测试 CDN
m.example.com/static/* host test-cdn.example.com

# mock: 登录态过期响应，仅用于异常状态验证
www.example.com/api/session resBody://{session-expired.json}

团队共享时推荐什么流程？

比较稳妥的方式是建一个 whistle-rules 仓库，把 rules-dev、rules-test、values、README.md 放进去。新同学克隆仓库后，用软链接或启动参数指向对应规则文件；改公共规则时走 Pull Request，至少让相关业务同学看一眼。不要直接让所有人共用同一个可写文件，否则一次错误保存就会影响整组。

bash
git clone git@example.com:team/whistle-rules.git ~/whistle-rules
ln -sf ~/whistle-rules/rules-dev ~/.whistle/rules
w2 restart

Values 和环境变量怎么配合？

Values 适合放可复用的 mock 数据和变量，例如本地域名、端口、通用响应体。环境差异很大的内容不要硬塞进一份文件，可以拆成 values-dev.json、values-test.json，再通过文档说明切换方式。敏感 token、Cookie、内网账号不要提交到仓库，最多提供字段模板。

json
{
  "localApi": "127.0.0.1:3001",
  "corsHeaders": {
    "access-control-allow-origin": "*",
    "access-control-allow-credentials": "true"
  }
}

追问

公共规则和个人规则怎么划分？

公共规则放团队都需要、行为稳定、风险可控的配置，个人规则放本地端口、临时 mock 和实验性代理。取舍点在于共享越多，上手越快，但误伤范围也越大。边界可以定得很明确：会影响真实登录、支付、下单、生产域名的规则，默认不进公共文件。常见踩坑是把自己本地 127.0.0.1 的代理提交上去，别人一拉规则接口就全挂。

规则顺序冲突时怎么排查？

先在 Network 里看请求是否命中预期规则，再把精确路径放到通配符前面，必要时临时注释掉宽泛规则验证。取舍是规则写得越通用越省事，但排查时越难判断谁覆盖了谁。边界上，不建议用一个 *.example.com * 之类的大范围规则解决所有问题。踩坑最多的是正则和通配符混用后，以为后面的精确规则会覆盖前面的宽泛规则。

要不要把 whistle 规则纳入代码评审？

如果规则会影响多人联调，就应该评审，至少确认域名、路径、mock 数据和删除时间。取舍是评审会增加一点流程成本，但能减少半天都查不出的代理误配。边界可以放宽在个人规则和临时验证上，这类不需要走 PR。踩坑是没有 owner 的规则越积越多，半年后没人敢删，最后变成第二套隐形环境配置。

多环境切换用复制文件还是启动参数？

少量环境可以复制文件后 w2 restart，但团队协作更推荐保留多个规则文件，用启动参数或软链接切换。取舍在于复制文件直观，启动参数更可追溯。边界是不要在同一份规则里同时启用 dev、test、prod 三套代理，除非你能保证域名完全隔离。踩坑是切完环境忘记重启 whistle，或者浏览器缓存让你误以为规则没生效。

规则里能不能放敏感信息？

不建议放，尤其是 Cookie、Authorization、内部账号和生产 token。取舍是写进去调试最快，但一旦提交仓库或截图分享，泄露成本很高。边界是公共仓库只允许放示例值和字段结构，真实值放个人本地 Values 或环境变量。踩坑是 mock 登录态时顺手贴了真实 Cookie，后来被多人复用，排查权限问题会非常混乱。