Chrome DevTools复制请求并保留关键请求头的实现方法

调接口遇到问题时，最有价值的材料通常不是一张页面截图，而是 Network 面板里那条完整请求。Chrome DevTools 可以把选中的请求复制成 cURL 或 fetch，连同部分请求头、查询参数和请求体一起带走。正确做法是先打开 Network 再触发请求，然后筛选目标行，最后从右键菜单复制；如果先打开页面后才打开面板，早先的请求可能根本没有被记录。

官方地址：https://developer.chrome.com/docs/devtools/network/

先让 Network 记录到目标请求

按 Command+Option+J（macOS）或 Control+Shift+J（Windows/Linux）打开 DevTools，再切到 Network。刷新页面，或者重新点击会触发接口的按钮。每一行代表一个资源，常用判断列是 Status、Type、Initiator、Size 和 Time。目标请求出现后再进行复制，结果比从日志、截图中猜参数可靠。

用筛选和 Headers 确认复制对象

请求较多时，在 Filter 输入接口路径片段，或用 fetch、xhr 缩小范围。点击目标行后，右侧详情通常从 Headers 开始：先核对 Request URL 和 Request Method，再看 Query String Parameters、Request Headers 和 Request Payload。这里的检查顺序很重要，因为同一路径可能同时有预检请求、重试请求和真正的业务请求。

从右键 Copy 菜单导出并保留关键头

确认请求行后右键，进入 Copy。需要命令行复现时选择 Copy as cURL，需要交给前端代码参考时选择 Copy as fetch。复制结果中的头字段由浏览器当前请求和 DevTools 版本决定，不是“所有请求头永久导出”；像 sec-ch-ua 这类浏览器生成字段通常没有业务复现价值，优先保留认证、内容类型、来源校验和业务自定义头。

# 复制出的命令只用于说明结构，请先脱敏再保存或分享
curl 'https://api.example.test/v1/orders?page=1' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer ' \
  --data-raw '{"status":"pending"}'

上面的 Authorization 和 Cookie 不应原样贴到工单、群聊或仓库。若复制后接口返回未登录，先判断会话 Cookie 是否过期；若返回 CSRF 错误，再核对令牌是否来自当前页面和当前请求。浏览器自动添加的 Host、Content-Length 等字段一般交由客户端重新计算。

无法复现时按四类原因缩小范围

第一类是请求选错：对照 Method、Status 和 Initiator，排除 OPTIONS、静态资源与重试行。第二类是会话态失效：Cookie、Authorization、临时签名和验证码都可能过期。第三类是上下文缺失：请求体、Origin、Referer 或 CSRF 令牌没有一起带出。第四类是客户端差异：浏览器会自动处理重定向、压缩、缓存和部分安全头。排查时保留原始请求的字段清单，再逐项删除，才能知道真正的必要条件。

常见问题

为什么右键菜单里找不到 Copy as cURL？

先确认右键点的是 Network Log 中的请求行，而不是空白区域或详情文本；不同 Chrome 版本的菜单名称可能略有变化，也可以在 Command Menu 中搜索复制相关命令。

复制的 cURL 能否直接放进生产脚本？

不建议。它往往含有个人会话、临时令牌和环境地址，应先脱敏，再把固定参数、认证方式和超时策略改成脚本配置。

复制请求头是不是越多越好？

不是。先保留认证、内容类型、来源校验和业务自定义头，再逐步删除浏览器噪声头，得到最小可复现请求。