Playwright 网络 HAR 记录器

问题：回放不稳定，往往是网络层没固定下来

Playwright 默认在测试过程中直连真实服务，每次跑测试，页面发出的请求都可能打到不同节点、拿到不同响应。只要某个接口返回的数据稍有变化——比如列表顺序不同、兜底文案多了一段、CDN 回了另一个版本——断言就会挂。排查这类失败通常要反复跑、反复比对 diff，最后发现代码根本没问题。

这个技能做了什么

它把 Playwright 的 routeFromHAR 能力封装成可复用技能，让测试运行时直接从 HAR 文件接管网络流量：

• 录制：触发一遍真实流程，把页面发出的请求与响应完整落盘成 HAR。此后每次回放都基于这份存档，而不是再次发起真实网络调用。
• 确定性回放：routeFromHAR 把请求匹配到 HAR 中记录的响应，同一份 HAR 每次都产生同样的结果，可以放进 CI 稳定跑。
• 选择性录制：只挑关心的接口入库，忽略埋点、统计这类噪声请求，避免 HAR 里塞满无关记录。
• 响应修改：录制完成后手工改某个响应体，用来构造边界场景，不必为了一个错误分支去改后端开关。
• API 模拟生成：从已有 HAR 反向整理出接口契约样例，方便对端或 mock server 直接使用。

典型流程是：先跑一遍把 HAR 存下来 → 检查并裁剪 HAR → 把 HAR 接入测试用例 → 在无网络或弱网环境下重复执行。

适用边界

它解决的是响应确定性问题，不是性能压测工具，也不会自动写断言或补齐用例，用例仍需自己维护。

HAR 是录制时刻那一轮真实交互的快照。后端改了字段、前端新增了请求，HAR 不会自动同步，需要重新录制，否则回放会按旧数据继续跑，看起来「通过」其实已和线上行为脱节。

routeFromHAR 的匹配规则有它自己的语义，带动态参数（时间戳、随机 id）的 URL 如果不处理，容易出现匹配不上或错误命中，建议录制后主动清理这类字段，或在用例里统一处理。

另外，HAR 只记录 HTTP 层，WebSocket 与 Service Worker 内部的逻辑不在覆盖范围内。