whistle 代理工具适合解决哪些前端调试问题？
whistle 是基于 Node.js 的本地代理调试工具，常用来抓包、改请求、改响应、做接口 Mock、切换测试环境和调试移动端流量。它不像 Charles、Fiddler 那样主要依赖图形化操作，而是把很多能力放进规则文本里，适合前端团队沉淀一套可复制的调试方案。这个取舍很现实：规则可共享、可复用，但第一次配置代理、证书和规则时更容易出错。
安装一般只需要 Node 环境：
npm install -g whistle w2 start w2 status
启动后默认控制台是 http://127.0.0.1:8899。浏览器或手机把 HTTP/HTTPS 代理指向运行 whistle 的机器和 8899 端口，就能看到请求列表。HTTPS 调试必须安装并信任根证书，否则只能看到 CONNECT 隧道，看不到明文请求和响应。
常见规则可以这样写：
api.example.com 127.0.0.1:3000 https://api.example.com/user file:///Users/me/mock/user.json www.example.com resHeaders://{cors}
第一行适合把接口转到本地服务，第二行适合固定 Mock 响应，第三行常用于临时验证跨域响应头。whistle 适合快速定位和验证问题，但不适合替代正式网关、灰度平台或线上流量治理。规则越多，越要按项目和场景分组，否则后来的人很难判断异常响应来自后端，还是被本地代理改过。
追问
whistle 和 Charles、Fiddler 怎么选？
如果只是偶尔看请求、导出 HAR 或给测试复现问题，Charles 这类图形化工具更容易上手。whistle 更适合开发团队，因为规则可以复制到文档，也方便做 Mock 和转发。它的边界是本地环境依赖更强，Node、系统代理、证书任一环节错了都会影响结果。实际项目里可以开发用 whistle，非技术同学继续用图形化抓包工具。
HTTPS 抓包为什么经常看不到响应内容？
最常见原因是没有安装或信任 whistle 的 HTTPS 根证书，浏览器只把请求当作加密隧道转发。第二个坑是 App 做了证书锁定，即使系统信任根证书也会拒绝中间人证书。还有一种情况是代理只配到浏览器，没有配到手机、模拟器或命令行进程。排查时先用普通 HTTPS 页面验证证书链，再调试目标 App。
用 whistle Mock 接口有什么边界？
Mock 适合验证前端分支、异常态和字段兼容，比如空列表、权限不足、接口超时。它不能证明真实接口契约完全正确，因为 Mock 数据很容易落后于后端变化。踩坑最多的是只 Mock 成功响应，结果上线后 401、429、500 分支没人处理。比较稳的做法是把常见错误码也做成规则，联调结束后再回真实环境验证一次。
移动端调试时需要注意什么？
手机代理地址要填电脑局域网 IP，不能填 127.0.0.1。如果公司网络有隔离策略，手机可能连不到电脑的 8899 端口，这时要换热点或确认防火墙放行。HTTPS 调试还要在手机上安装并信任证书，iOS 需要额外开启完全信任。调完后记得关闭手机代理，否则离开办公网络后会出现网页都打不开的假故障，也会误导后续排查。