一、联调最怕一句话------"我这边没问题"
前后端分离开发后，前端和后端往往由不同的人、不同的节奏推进。联调时经常出现这样的场景：
-
前端说："接口报错了，你后端看下。"
-
后端说："我 Postman 本地是好的，你前端传参有问题。"
-
产品说："我不管，明天要上线。"
如果没有一套排查方法，联调就会变成"扯皮大会"。但事实上，前后端分离后，浏览器和后端之间隔着一条完整的 HTTP 链路：
用户操作 → 前端代码 → HTTP 请求 → 网关/后端 → 数据库/缓存/第三方 → HTTP 响应 → 前端渲染
错误可能发生在任何一段。我们要做的不是站队，而是沿着这条链路，一段一段找证据。
核心原则只有一句话：
先看请求有没有发，再看请求对不对；
再看后端有没有收到，再看响应对不对；
最后看前端渲染对不对。
二、先建立责任地图：前端、后端、契约、环境
很多同学以为错误只有两种：前端错或后端错。
实际联调中，至少有四类问题：
| 层级 | 主要负责 | 常见问题 | 关键证据 |
|---|---|---|---|
| 前端/浏览器 | 页面、状态、路由、参数组装、渲染 | 事件没绑定、参数没带、token 没加、字段映射错 | Network、Console、Vue/React DevTools |
| HTTP/接口契约 | 前后端共同遵守 | URL、方法、Header、Body、状态码、响应结构不一致 | 接口文档、Swagger/OpenAPI |
| 后端/网关 | 业务逻辑、鉴权、数据库、缓存、第三方 | 500、业务异常、权限错误、查询为空 | 后端日志、traceId、APM |
| 环境/网络 | 域名、代理、CORS、DNS、证书、超时 | 本地好线上坏、跨域、502/504 | curl、网关日志、浏览器 Network |
所以，判断错误来源时，不要只问"谁的锅"，而要问：
-
请求发出来了吗？
-
请求符合接口契约吗？
-
服务端收到了吗？
-
响应符合契约吗？
-
前端正确处理响应了吗？
三、标准排查流程：一张流程图走到底
下面这张图建议在联调时直接照着走。
四、最关键的交叉验证：用 curl / Postman 再发一次
浏览器 Network 面板只能告诉你"浏览器看到什么"。
要判断是前端问题还是后端问题，最好做一次交叉验证：
在 Network 里右键请求 → Copy as cURL。
然后到终端执行，或者粘贴到 Postman 里，用相同的：
-
URL
-
请求方法
-
Header
-
token
-
请求体
-
环境
再发一次。
判断规则很简单：
-
curl/Postman 成功，浏览器失败 → 优先查前端代码、浏览器环境、CORS、代理、拦截器。
-
curl/Postman 也失败 → 优先查后端接口、鉴权、网关、网络、数据库。
-
两者都成功，但页面还是错 → 优先查前端渲染、字段映射、状态更新。
-
两者都失败，但后端说本地成功 → 查环境差异、配置、数据库、分支版本。
示例：
javascript
curl -X POST 'https://api.example.com/login' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer xxx' \
-d '{"account":"test","password":"123456"}'如果这条命令能成功，而页面失败，就不要急着说"后端有问题"。
先看前端是不是字段名写错了、token 没带、代理没配、请求拦截器改了参数。
五、常见现象速查表
| 现象 | 优先怀疑 | 怎么确认 |
|---|---|---|
| 点击按钮完全没请求 | 前端 | Console 是否有 JS 报错？事件是否绑定？表单校验是否拦截？ |
| 请求 404 | 前端路径 / 后端路由 / 网关转发 | 对比接口文档、baseURL、网关配置 |
| 请求 400 | 前端参数 / 后端校验 | 看请求体字段名、类型、必填项、后端校验日志 |
| 请求 401/403 | token / 权限 | 看 Header 是否带 token、是否过期、角色权限是否足够 |
| 请求 500 | 后端异常 | 看 traceId、后端堆栈；同时看前端是否传了 null/脏数据 |
| CORS 跨域 | 后端配置 / 前端代理 | 浏览器有请求，后端可能也收到，但响应被浏览器拦截 |
| 200 但数据为空 | 后端查询 / 数据 / 契约 | 看 SQL、日志、数据库；确认字段名和结构 |
| 200 数据对但页面不显示 | 前端 | 看字段映射、状态更新、条件渲染、key 是否重复 |
| 超时 504 | 后端性能 / 网关 / 网络 | 看接口耗时、慢 SQL、第三方依赖、网关超时配置 |
| 本地好线上坏 | 环境/配置 | 对比环境变量、域名、数据库、分支、依赖版本 |
记住：
500 不一定是后端全责，404 不一定是前端全责，CORS 也不一定只是后端问题。
关键是看证据落在哪一段。
六、一个例子：登录接口报错，到底怪谁？
前端页面点击登录，提示"登录失败"。
你打开 Network，看到：
html
POST /api/login
Status: 400 Bad Request
请求体：
{
"username": "tom",
"password": "123456"
}
响应体：
{
"code": 40001,
"message": "account is required"
}这时可以判断：
-
请求已经发出。
-
后端也收到了。
-
后端返回 400，说缺少
account。 -
接口契约要求字段是
account，前端传的是username。
结论：主要是前端字段名与契约不一致。
但如果后端接口文档没写清楚，或者文档写的是 username，代码却要 account，那就是契约问题。
如果后端因为前端传错字段就直接 500，那后端健壮性也有问题。
所以真实结论往往不是"前端错"或"后端错"，而是：
契约不一致 + 前端未按最新文档传参 + 后端校验提示不友好。
联调的价值，就是把这些边界问题找出来。
七、沟通模板：不要只说"报错了"
给实习生一个很实用的沟通模板：
html
环境：测试环境
时间：2026-10-13 15:30
账号：test01
页面：登录页
操作步骤：输入账号密码，点击登录
期望结果：登录成功，跳转首页
实际结果：提示登录失败
Network：
- 请求：POST /api/login
- 状态码：400
- 请求体：{"username":"tom","password":"123456"}
- 响应体：{"code":40001,"message":"account is required"}
- traceId：abc-123
已做验证：
- 用 curl 同样参数请求，也返回 400
- 接口文档写的是 account 字段
怀疑点：
前端字段名与接口契约不一致，请后端确认字段要求。这样的沟通，后端一眼就能看懂，也不会觉得你在甩锅。
前端也一样，看到 traceId 和日志，能快速定位。
八、结尾：会定位问题，比会写代码更早让你融入团队
前后端联调时，判断错误来自前端还是后端，不靠感觉，靠证据链。
最后送你一个口诀：
一看请求发没发，
二看请求对不对，
三看后端收没收到，
四看响应码和体，
五看前端渲染对不对。
对实习生和大三大四同学来说，联调能力是非常重要的工程素养。
它考验的不只是你会不会写 Vue、React、Spring Boot，更考验你能否：
-
复现问题；
-
收集证据；
-
缩小范围；
-
清晰沟通；
-
协作解决。
真正成熟的开发者，不会说"这不是我的问题"，而会说：
"我观察到请求已经发出，状态码 400，请求体和接口文档不一致，我们可以先对齐字段名。"
这，就是从前端或后端"单点开发"，走向团队交付的第一步。