Chrome DevTools 152 网络请求重发怎么用：二进制请求体核对与复现边界

排查一个只在特定请求体下出现的接口问题时，最怕的是“看见请求”却复现不了请求。Chrome DevTools 152 把 Network 面板里的 Replay XHR 改成了 Resend，并把能力扩展到可通过浏览器发出的 fetch 请求；Payload 面板还增加了 Base64、Hex、UTF-8 解码选项。这样可以先保留现场，再决定是重发、改参数，还是把问题交给后端继续核对。

Chrome DevTools 152 解决了哪一段调试断点

旧的 Replay XHR 名称容易让人以为它只服务于 XHR。Chrome 官方在 DevTools 152 中将入口改为 Resend，覆盖标准 fetch 与 XHR，并在请求记录中显示执行上下文和控制台来源。对前端工程师来说，价值不在于多了一个右键菜单，而在于能把“页面刚刚发过的那一次请求”重新放回浏览器网络栈里核对。

这项能力仍然受浏览器当前状态约束：Cookie、Authorization、CSRF 字段、Service Worker、缓存和服务器端幂等规则都会影响结果。重发成功只能说明这次请求再次到达并得到响应，不能单独证明原始故障已经修好。

先用一个最小请求把现场固定下来

准备一个页面按钮，让它发送一个普通的 JSON 请求。调试时不要先改成命令行调用，因为那样会把浏览器上下文和跨域行为一起换掉。

async function loadPreview() {
  const response = await fetch('/api/preview', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ documentId: 'demo-17', mode: 'preview' })
  });
  return response.json();
}

打开 DevTools 的 Network 面板，勾选 Preserve log，点击按钮后用 Type 过滤 Fetch/XHR。先记录 Request URL、Method、Status、Initiator 和 Payload，再开始重发。这样做的检查点是：列表中只留下目标请求，Payload 与页面代码中的字段一致，响应状态也被完整保留。

Resend 的准确入口和一次复现顺序

在目标请求上点右键，选择 Resend。Chrome 会在 Network 面板中创建一条新的请求记录；如果原记录来自普通 fetch，重发结果仍然属于浏览器发出的 fetch 请求，不必手工复制成 XHR。

1. 先看新记录的请求时间和 Initiator，确认它确实是刚才的重发，而不是页面自动触发的第二条请求。
2. 比较 Request Headers，重点核对 Cookie、Origin、Referer、Content-Type 和授权字段是否仍在有效期内。
3. 比较 Payload，确认请求体没有因为页面状态变化而换成另一份文档或筛选条件。
4. 最后比较 Status、Response 和 Timing。若状态码相同但响应业务码不同，应继续查服务端幂等、缓存或一次性令牌，而不是反复点击。

可见的成功状态不是“列表多了一行”这么简单，而是新记录的 URL、方法、请求体摘要和响应业务结果都与目标现场一致。若请求出现 CORS、登录过期或前置页面状态缺失，Resend 的失败本身也提供了有效线索。

二进制 Payload 怎么判断该选哪种解码方式

当请求体不是可读 JSON 时，打开 Payload 标签页，选择对应的解码方式。Chrome DevTools 152 为二进制或压缩请求体提供 Base64、Hex 和 UTF-8 选项；三者是查看同一批字节的不同表示，不是三次不同的网络请求。

• Base64：适合核对接口日志或测试夹具里已经采用 Base64 保存的字节串；它是编码，不是解压。
• Hex：适合看魔数、固定头和字节边界。例如先确认文件头是否符合预期，再判断后面的字段。
• UTF-8：只在这批字节本来就是文本时使用。出现替换字符并不等于请求一定损坏，也可能是编码方式选错。

实际核对时建议按“长度—固定头—局部字段—服务端结果”的顺序走。不要把 Payload 面板渲染出的可见字符直接粘回业务请求，尤其是压缩数据、签名字段和含有不可见字节的协议。

哪些情况不能把 Resend 当成真实回放

Resend 复现的是当前浏览器还能重建的请求。下面几类场景需要额外记录证据：

• 请求带有时间戳、Nonce 或一次性签名，重发时服务端会按设计拒绝。
• 请求依赖页面刚刚生成的临时文件、短期 Cookie、Service Worker 缓存或内存状态。
• 接口有写入副作用，第一次请求可能已经创建订单、提交表单或消耗额度。
• 问题只在弱网、特定代理、特定设备或跨站上下文出现，单次 Resend 不能代表所有客户端。

对有副作用的接口，优先在测试环境复现，或先确认服务端提供了幂等键和可回滚路径。需要对比原始字节时，保存请求摘要与合法的脱敏样本，不要把真实 Cookie、Authorization 或个人数据复制进工单。

兼容性和团队协作怎么落地

Chrome DevTools 的新入口属于开发者工具能力，不应写进线上业务逻辑的兼容判断。团队可以把它固化成一张调试记录：浏览器版本、页面 URL、请求方法、执行上下文、脱敏后的请求体长度、状态码、业务码和是否存在一次性字段。

如果团队成员使用不同 Chrome 渠道，先确认对方是否已经拥有 DevTools 152 的 Resend 和二进制查看能力；否则用“复制请求关键字段 + 保存 HAR 或脱敏样本”的方式交接，不要只写一句“点 Replay XHR”。

常见问题：重发、解码和安全边界

Resend 和复制为 fetch 有什么区别？

Resend 直接基于 Network 记录发起新的浏览器请求，适合先保留现场。复制为 fetch 更适合把请求结构带回代码或测试夹具，但复制内容需要重新检查敏感字段和过期参数。

Payload 选 UTF-8 后能看到文字，说明接口收到的就是文字吗？

不能。UTF-8 只是对字节的一种解释。要确认接口收到的内容，应结合请求体长度、固定头、服务端解析日志和响应业务码一起判断。

为什么重发一次成功，页面再次点击却失败？

常见原因是一次性令牌、页面状态、幂等规则或服务端数据已经改变。把两次请求的 Headers、Payload、Timing 和业务响应并排比较，比继续重复重发更快。

把一次“点一下重发”变成可复核证据

Chrome DevTools 152 的 Resend 适合缩短从网络现场到最小复现的距离，二进制 Payload 查看则适合先确认字节到底是什么。真正可靠的结论仍要落在可重复的请求条件、脱敏后的输入、服务端结果和副作用检查上。调试结束后清理保存的认证字段与本地样本，避免把排障材料变成新的泄露入口。