Playwright BiDi 大小报告：防止代理带宽指标把响应头计入正文
一项于 2026 年 9 月 12 日提交的 Playwright 开放问题报告称，Chrome 通过实验性 BiDi 后端运行时，request().sizes() 可能高估 responseBodySize。复现中的正文为 2,000 字节，BiDi 结果为 2,151 字节，多出的 151 字节与对照运行的响应头大小一致。
这是一项尚未关闭的问题报告，不代表已确认的普遍生产缺陷，也不说明代理本身出错。它提醒代理采购与数据团队：不同浏览器网络后端可能赋予遥测字段不同含义，不能把单一自动化指标直接视为带宽真值。
内部研究来源：Microsoft Playwright 问题“bidi reports transfer size as responseBodySize, so request().sizes() over-reports the body by the header size”，提交日期 2026 年 9 月 12 日。
报告说明了什么
报告使用固定 2,000 字节响应。CDP 路径记录 2,000 字节正文，而 BiDi Chrome 项目记录 2,151 字节；压缩与分块响应也出现类似偏高。报告推测同一协议值被同时用于传输大小和编码正文大小，但两者在 Playwright 内部本应分开。
BiDi 后端仍属实验性，问题也仍开放。实际影响必须在团队自己的 Playwright 版本、浏览器通道和代理配置中复现。
为什么会影响代理决策
代理试用常按每 MB 成本、每个成功页面字节、压缩节省或流量异常评分。如果名为正文大小的字段混入响应头，小型 API 响应会受到更大比例的偏差。路由之间 Cookie、缓存标头或诊断标头不同，也可能制造虚假的效率差异。
建立确定性回归测试
在自有或获准夹具返回 0、100、2,000 与 100,000 字节的固定正文。先使用稳定标头，再只增加一个已知长度的大响应头。分别测试 identity、gzip 与分块传输。
记录 Playwright 版本、浏览器通道、网络后端、代理路由别名、状态、声明长度、解码正文、编码正文、响应头、报告正文大小、报告传输大小和正文摘要。不得记录代理密码、Cookie、授权值或私有载荷。
对照四层证据
第一层是夹具已知长度与摘要；第二层是实际读取正文的字节数；第三层是自动化框架报告值；第四层是在获准条件下采集的网络或源站计数。
保持夹具一致，分别运行直连、代理、CDP 和 BiDi。随后端变化的差异不能自动归因于代理；随路由变化的差异则需要继续拆分标头、压缩、缓存和内容表示。
使用响应头增量挑战
两次返回完全相同的正文，第二次只增加一个已知长度标头。如果正文摘要和实际字节不变，而 responseBodySize 按标头长度增加，就证明指标混合了不同层。
应在多个载荷大小上重复，以量化小对象成本模型的偏差。
明确区分三类大小
- 解码正文：内容解码后应用得到的字节；
- 编码正文：压缩表示的字节；
- 传输总量：编码正文、标头及测量源定义的协议开销。
仪表盘必须标注层级。代理账单应以供应商公开计费定义为准，再用固定夹具和独立计数对账。
上线检查清单
- 每条结果固定 Playwright 版本、浏览器通道和后端；
- 使用多种已知正文长度；
- 只改变标头并测量增量；
- 验证适用的解码与编码摘要；
- 分开直连和代理；
- 不合并 CDP 与 BiDi 数值；
- 正文、标头和传输总量分字段；
- 从 trace 删除凭据和隐私数据；
- 升级后重新运行；
- 按已验证完成结果做采购判断。
常见问题
BiDi 一定会高估代理流量吗？
不一定。报告针对特定的 Playwright next 版本与实验后端，必须在实际环境复现。
多出的字节是代理添加的吗？
不一定。报告将差异指向遥测映射。只有直连与代理对照才能隔离路由影响。
代理成本应该使用哪个数字？
使用供应商定义的计费层，并以已知载荷对账；同时保留解码正文、编码正文和总传输三个字段。
相关 98IP 指南
使用代理带宽成本估算建立计费模型，并结合gzip 与 Brotli 完整性测试及Playwright keep-alive 问题报告。
合规说明
仅在自有或明确授权系统测量流量，遵守速率限制、隐私承诺和平台规则。必须清除 trace 中的秘密信息，不得利用代理测试规避访问控制。
