Fetch请求在Chrome Network面板中明确标记为fetch类型，需点击Fetch/XHR按钮或输入关键词筛选才能定位；必须提前开启面板、确保录制为红色、勾选Preserve log并禁用缓存以完整捕获。
Fetch 请求在 Chrome Network 面板中会明确标记为 Fetch/XHR 类型，和传统 XMLHttpRequest 一样可被完整捕获——但需注意它不会出现在“JS”或“Other”分类里，必须主动筛选才能精准定位。
确保请求被完整捕获
Fetch 是 JavaScript 主动发起的异步调用，若页面已加载完成再打开 DevTools，该请求很可能已被执行完毕、无法捕获。务必在操作前就开启 Network 面板：
- 按 Cmd + Option + I（Mac）或 Ctrl + Shift + I（Windows/Linux）打开开发者工具
- 切换到 Network 标签页，确认左上角圆形录制按钮为红色
- 勾选 Preserve log，防止滚动触发新 Fetch 时因页面跳转丢失历史记录
- 如需模拟首次加载，可配合勾选 Disable cache，避免缓存响应干扰分析
快速定位 Fetch 请求
页面中 JS 脚本可能发起多个 Fetch，直接扫列表效率低。推荐组合筛选法：
- 点击顶部预设按钮 Fetch/XHR，过滤掉 HTML、CSS、图片等静态资源
- 在 Filter 输入框输入关键词，比如接口路径片段（
/api/list）、参数名（offset=）或域名 - 若知道是 POST 请求，输入
method:POST；若是带 token 的请求，可尝试authorization或cookie - 滚动页面触发瀑布流加载时，观察新增条目中 Type 列显示 fetch 的那一行（Chrome 120+ 明确标注）
逐阶段解读瀑布流时间轴
点击目标 Fetch 请求，在下方 Timing 标签中能看到完整生命周期分解。重点关注以下阶段（鼠标悬停可看毫秒值）：
立即学习“Java免费学习笔记（深入）”；
- Queuing：浏览器排队等待发起请求，可能受同域并发限制（默认 6 个连接）或高优先级资源抢占
- Stalled：卡在 DNS 查询前或代理协商阶段，常见于本地代理配置异常
- DNS Lookup：域名解析耗时，若持续 >100ms，需检查 DNS 设置或考虑 HTTP/2 多路复用优势
- Initial connection：含 TCP 握手与 TLS 协商，HTTPS 站点该阶段偏长属正常，但超过 500ms 值得排查证书链或 CDN 配置
- Waiting (TTFB)：从请求发出到收到第一个字节的时间——这是后端处理性能的核心指标，>1s 通常说明服务端逻辑慢或数据库查询未优化
- Content Download：实际下载响应体的时间，与返回数据量正相关；若该阶段长但 TTFB 短，说明接口返回了大量冗余字段
结合 Headers 和 Response 深度验证
仅看时间不够，还需确认请求是否真正符合预期：
- 在 Headers 标签中检查 Request Headers：确认
Accept、Content-Type、Authorization或Cookie是否携带齐全（漏掉任一关键 header 都可能导致 401/403） - 查看 Request Payload（POST/PUT 请求才有）：确认 JSON body 结构、字段名大小写、空值处理是否与后端约定一致
- 切换到 Response 或 Preview 标签：验证返回是否为有效 JSON，是否有
data包裹、错误码嵌套等前端需适配的结构 - 留意 Status Code 和 Response Headers 中的
Content-Encoding: gzip，判断是否启用压缩以减少传输体积
