whistle Values 如何管理多环境配置和 mock 数据？
whistle 的 Values 可以理解成一份可复用的变量仓库，用来存放域名、端口、token、mock JSON、响应片段等配置。规则里用 {key} 引用后，同一份值可以被多条规则复用，切环境时只改 Values，不用把规则逐行改一遍。它最适合处理“规则稳定但数据经常变”的场景，比如本地、测试、预发三套接口地址，或者同一个接口在不同用例下返回不同响应。边界也要先说清楚：Values 不是数据库，不适合放大量动态数据，更不要放生产密钥；它解决的是代理调试里的配置复用问题。
常见启动方式如下，先确认 whistle 正常运行，再进入 http://127.0.0.1:8899/ 管理界面。
npm i -g whistle w2 start -p 8899 w2 status
在 Values 面板里可以创建 env.json，内容保持简单、稳定：
{ "apiHost": "http://127.0.0.1:3000", "testHost": "https://test.example.com", "userId": "10001", "profileMock": { "name": "Tom", "role": "admin" } }
规则中再引用这些值：
^https://api.example.com/(.*) {apiHost}/$1 https://api.example.com/user?id={userId} resBody://{profileMock}
这个写法的好处是规则仍然表达“流量怎么转发”，Values 只负责“具体值是什么”。如果团队多人共用，建议把 key 命名成 env.apiHost、mock.profile.admin 这类层级语义，避免 host1、data2 这种几天后没人敢动的名字。
追问
Values 和 Rules 应该怎么分工？
Rules 管流量匹配、转发、替换和注入，Values 管可复用的数据。取舍标准很简单：如果一段内容会被多条规则引用，或者经常随环境变化，就放到 Values；如果它只服务一条规则，直接写在 Rules 里反而更直观。踩坑最多的是把整套规则都“变量化”，最后打开规则只看到一堆 {xxx}，排查时必须来回切面板。Values 应该降低重复，不应该降低可读性。
多环境配置怎么切换最稳？
建议为不同环境建独立 Values，例如 local.json、test.json、pre.json，每份保持相同 key，只替换 value。这样规则文件不用变，切换时只启用对应 Values，团队成员也容易对齐。边界是同一时间不要启用多份同名 key 的 Values，否则后加载或更高优先级的值会覆盖前面的值，表现像“规则偶尔失灵”。如果必须临时覆盖，最好在 key 名里写清楚 override，用完立刻关闭。
Values 里能不能放接口 mock 响应？
可以，尤其适合体积不大的 JSON 响应、错误码、空列表、权限状态等固定场景。取舍在于维护成本：几十行以内的 mock 放 Values 很方便，几百行甚至带复杂逻辑时，应该改用文件、插件或脚本处理。常见踩坑是 JSON 少了引号或多了尾逗号，规则没有明显报错，但响应内容就是不对。写 mock 时先用 JSON 校验工具检查，再用 Network 面板确认最终响应体。
Values 适合保存 token 和账号信息吗？
临时调试 token 可以放，但不建议长期保存真实生产凭据。whistle 是本地代理工具，团队共享配置、截图或导出时很容易把敏感值带出去。更稳的做法是只保存占位符，例如 {debugToken}，真实值由个人本地单独维护，或者在脚本里从环境变量读取。边界是测试环境的低权限 token 可以接受，生产管理员 token 不应该进入 Values。
Values 不生效时怎么排查？
先看 key 是否拼错，再看对应 Values 是否启用，最后看规则命中是否符合预期。可以把响应临时改成固定文本验证引用是否成功，例如 resBody://{profileMock}，比直接排查完整代理链更快。另一个坑是值里包含特殊字符、换行或 URL 参数时没有正确转义，导致规则解析和预期不同。排查时一次只改一个变量，并在 Network 里查看实际请求 URL、响应头和响应体。