Whistle对比实战：一次登录故障复盘

步骤一：建立案例基线并接入流量

案例发生在前后端分离项目：账号密码校验成功，页面进入首页后两秒又跳回登录页。团队先记录接口状态、发生时间和测试域名，关闭旧Mock规则，再启动Whistle并为浏览器配置代理。Network中只保留测试域名，避免第三方资源干扰。

同一问题若仅用浏览器开发者工具，也能看到当前标签页请求，但页面跳转后上下文容易分散；Charles可以完整捕获进程流量，不过需要额外用域名过滤器整理列表。此时Whistle对比的优势不是抓得更多，而是过滤与后续规则改写处于同一界面。

步骤二：沿请求顺序锁定异常

登录接口返回200，并在响应体中给出token；紧接着的用户信息接口却返回401。检查请求详情后发现Authorization头存在，但测试环境新增的网关要求Cookie中同时携带会话标识。前端开发者工具能确认现象，却不便在不改代码的情况下持续为多次请求补同一字段。

团队没有立即认定前端有错，而是对照正常环境的请求头、响应头与Cookie作用域。结果显示服务端下发Cookie时Domain仍是旧测试域名，浏览器因此拒绝在新域名请求中携带。这个差异比单纯查看状态码更接近根因。

步骤三：用规则构造可重复验证

为避免等待后端发布，团队在Whistle中建立仅匹配登录响应的规则，将Set-Cookie中的Domain替换为当前测试域名，同时保留原始过期时间和安全属性。重新登录后，用户信息接口连续返回200，刷新页面也未丢失状态，说明域名属性确实是关键变量。

Charles同样可通过Rewrite完成验证，但配置过程更偏菜单操作，分享时需要导出专用配置。Whistle规则可直接复制给另一位测试人员，对方替换目标域名即可复现。mitmproxy也能完成，而且适合批量自动化，不过为一次属性替换编写脚本成本偏高。

步骤四：还原环境并形成复盘结论

验证完成后，团队停用改写规则、清除测试Cookie，再次确认故障恢复，排除缓存偶然性。随后提交服务端配置修复，并在发布后使用原始流量回归。最终结论是：浏览器工具适合快速观察，Charles适合成熟的桌面抓包流程，Whistle更适合把排查假设转成可共享规则。临时改写只能用于验证，不能作为线上修复。