Network：不要相信“代码应该发了”，看浏览器实际发了什么

什么时候使用 Network

• 点击保存、登录、生成以后没结果。
• 页面提示 401、404、500。
• 前端说发送了 text，后端却说没有。
• 本地请求成功，线上请求了错误域名。
• 页面一直转圈，请求长时间 Pending。

打开并捕捉一次请求

1. 打开开发者工具。
2. 点击顶部 Network；看不到时点 »。
3. 点击左上角清空按钮。
4. 确认红色圆点处于记录状态。
5. 回到页面执行一次操作。
6. 再回到 Network 查看新出现的行。

Network 只记录打开以后发生的请求。先操作、后打开，可能什么也看不到。

请求太多时怎样筛选

常用筛选：

Fetch/XHR     前端 API 请求
Doc           页面本身
JS            JavaScript 文件
CSS           样式文件
Img           图片

查保存留言接口时，先点 Fetch/XHR，再在过滤框输入 messages。

点开请求以后看五个位置

Headers

Request URL       实际地址
Request Method    GET / POST 等
Status Code       200、401、500 等

Payload

前端实际发送的数据：

{ "text": "你好" }

代码里写了 userId，不代表 Network 一定真的发送了。

Preview

浏览器整理后的响应，适合快速展开 JSON。

Response

服务器原始返回内容：

{ "error": "missing session" }

Timing

请求各阶段耗时。一直 Pending 时可以查看是否卡在等待服务器响应。

用状态码决定下一步

没有请求

前端按钮事件没运行，或 fetch 前已经报错。看 Console。

200 / 201

请求成功。继续确认 Response 是否正确、前端是否更新 state、数据库是否符合预期。

400

Payload 格式或字段不符合后端规则。对比请求数据和 API 要求。

401

缺少或失效的登录身份。看 Cookie、Authorization 是否应当发送，但不要公开真实值。

403

服务器认识你，但当前账号没有这项权限。

404

地址没有对应路由、路径拼错，或部署平台重写规则不正确。

429

请求太快、额度不足或服务限流。

500

后端处理失败。带着请求时间和 Response 去看后端日志。

AI 留言板具体排查

预期请求：

POST /api/messages
Payload { "text": "你好" }
Response 201 { "id": 42, "text": "你好" }

实际没有请求

查 MessageForm 的 onClick 和 Console。

实际请求 /messages

前端地址少了 /api，对比后端路由。

Payload 是 { "message": "你好" }

后端读取 req.body.text，前后端字段名不一致。

返回 201，页面仍没变化

请求成功，回前端检查是否解析 JSON 和 setMessages。

Preserve log 什么时候用

登录后页面跳转，旧请求会消失。勾选 Preserve log 可以跨页面保留记录。

普通排错不一定一直勾着，否则旧请求会积累，容易看错。

Disable cache 什么时候用

开发时怀疑浏览器一直使用旧 JS 或旧响应，可以在 DevTools 打开期间勾选 Disable cache 进行一次验证。

它不是修复部署缓存的永久方案。

导出 Network 记录要小心

HAR 文件可能包含请求 Headers、Cookie、Token 和个人数据。发给 AI 或别人前必须检查和脱敏。

一份可复制记录

操作：点击保存留言
Request URL：
Method：
Status：
Payload：
Response：
耗时或 Pending：
同一时间后端日志：

官方参考：Chrome DevTools Network。

前端代码写的是 POST，但 Network 显示实际请求是 GET。排查时应该相信哪一个？

答案：先相信 Network 记录的实际行为，再回到代码查为什么最终方法变成 GET。