联调卡住的时间，都花在三类问题上

复盘一下联调时"卡住半小时"的时刻，基本逃不出三类：后端接口还没好，前端只能干等；控制台一屏 CORS 报错，不知道是配置问题还是别的问题；登录态莫名其妙失效，来回踢回登录页。

这三类问题各有固定的排查套路，工具也基本都是"打开网页就能用"的类型。这篇文章把套路一次讲全，下次遇到直接对号入座。

接口未就绪：Schema Mock 先行

后端没写完，前端不该被阻塞。前提只有一个：接口的返回结构（JSON Schema）先约定好。有了 Schema，API 响应模拟器就能按结构自动生成 Mock 数据——根据 JSON Schema 生成模拟响应，字段类型和格式都会照着定义填充，比如 email 类型给邮箱格式的值。

一段典型的接口约定：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "name": { "type": "string" },
    "email": { "type": "string", "format": "email" },
    "createdAt": { "type": "string", "format": "date-time" }
  },
  "required": ["id", "name"]
}

把它贴进工具，立刻得到一批可直接使用的假数据，列表页的渲染、分页、空态判断都能先跑起来。等后端接口就绪，切一下环境变量指向真实服务即可——前端从头到尾没有被等接口这件事阻塞。

异常演练：超时、404、限流都要演一遍

只测"正常返回"的前端，上线遇到异常一定翻车。加载态、错误提示、重试逻辑这些容错代码，需要主动制造异常来验证。

用HTTP 响应模拟器按需定制响应：它支持自定义状态码、响应头、延迟时间和数据模板，把测试地址填进前端的请求里，就能演练：

  • 延迟设 3 秒：验证 loading 状态和超时提示
  • 返回 404 / 500：验证错误页和错误提示文案
  • 返回 429：验证限流提示与重试逻辑
  • 自定义响应头：模拟分页头、鉴权头等特殊返回

十几分钟的配置，把上线后才能暴露的问题提前到开发期解决。

登录态排查：先看 exp 再怪后端

“登录态莫名失效"九成和 JWT 的过期时间有关。JWT 是三段 Base64URL 拼接的字符串，把 token 贴进 JWT 解析器，头部与载荷立刻变成可读的 JSON，过期时间一目了然：

1
2
3
4
5
6

{
  "sub": "10086",
  "role": "editor",
  "iat": 1790992800,
  "exp": 1790996400
}

exp 是秒级 Unix 时间戳，上面这个例子表示 2026-10-03 11:00（+08:00）过期，iat（签发时间）到 exp 正好 1 小时有效期。排查思路跟着走：

  • exp 已过：不是 bug，是 token 真过期了，检查刷新逻辑
  • exp 未过仍 401：十有八九是本地存的是旧环境签发的 token，清掉重新登录
  • 本地时间不准：客户端时钟偏差会让"还有 30 秒过期"变成"已过期”，先校时

项目里有自动刷新逻辑的，还有一个经典坑：多个并发请求同时发现 token 过期，各自发起一次刷新，后一次刷新作废了前一次刚拿到的新 token，之后所有请求集体失败。解法是给刷新逻辑加锁，或在请求拦截器里排队统一刷新。

顺带一提，JWT 前两段只是 Base64URL 编码，谁都能解开看——载荷里放手机号、身份证号属于事故，不是加密手段。

跨域定位：CORS 报错的三种真相

控制台报 CORS 错误时，先别急着改后端配置，三种可能要分清：

  1. 服务端确实没配：响应里没有 Access-Control-Allow-Origin 头，这是真配置缺失
  2. 预检（OPTIONS）被拦：带自定义头的请求会先发 OPTIONS 预检，网关或中间件把预检拦掉了，正式请求根本没发出去
  3. 真实错误被跨域报错掩盖：浏览器会把缺少 CORS 头的错误响应统一显示成跨域错误——接口实际返回 500 时，控制台看起来也像 CORS 问题

还有个容易忽略的干扰项：预检结果会被浏览器缓存一段时间。刚改完服务端配置仍然报错的，先用无痕窗口或强制刷新排除缓存干扰，再下结论。

分不清是哪种，用CORS 测试工具直接检测接口地址：它会测试目标接口的 CORS 配置并给出结果，还能生成对应的服务端配置代码，对照着就能确定是"没配"还是"配错"还是"被掩盖"。

两个高频小问题速查

时间戳差 8 小时：先确认单位——10 位是秒、13 位是毫秒，new Date(1790992800) 会得到 1970 年，因为忘了乘 1000。再看时区：后端返回 "2026-10-03T02:00:00" 这种不带时区的字符串时，前端会按本地时区解析，UTC 时间直接差 8 小时。拿不准就用时间戳转换核对一下，时间戳与日期互转，秒毫秒自动识别。排查日志时同理：按本地时间筛日志、日志本身按 UTC 存储，也是"明明报错了却查不到日志"的常见原因。

接口传参里的 Base64：排查网关日志时经常看到一长串 eyJ... 或乱码参数，用 Base64 编码工具解码还原，确认是不是编码问题再改代码——别在代码没毛病的地方浪费时间。

常见问题

后端 Schema 和真实返回对不上怎么办？

约定阶段就把 Schema 存档，Mock 阶段照 Schema 生成；接口就绪后先做一轮字段比对，不一致的回到 Schema 上修正——问题出在约定没文档化，而不是 Mock 本身。

exp 没过期还是 401，都检查过时钟了？

让后端把收到的 token 打出来对比：很多"莫名失效"是前端存了两个环境的 token（测试/预发），或者请求头里带了过期旧 token。用 JWT 解析器把两边 token 各解一次，一对比就现形。

CORS 配置了 Allow-Origin 怎么还报错？

带凭证（Cookie）的请求不允许 Access-Control-Allow-Origin: *，必须返回确切的域名；同时确认 OPTIONS 预检返回的是 2xx 且允许了请求头。逐项对照工具生成的配置代码，缺哪补哪。

小结

联调提速的本质是把"等"变成"演"：接口没好就按 Schema 生成 Mock，异常场景用响应模拟器主动制造，登录态问题先解析 JWT 看 exp，跨域问题先检测配置分清真相。这篇用到的工具——API 响应模拟器、HTTP 响应模拟器、JWT 解析器、CORS 测试工具、时间戳转换、Base64 编码——都收录在接口联调工具包专题里，联调前收藏一个页面，卡住的时间能省一大半。