先确认：真是 Token 的问题吗
登录昨天还好好的，今天所有接口突然返回 401 Unauthorized，第一反应往往是“账号被封了”。别急，先看两点：第一，登录接口本身是否正常——如果连登录都 401，多半是账号密码或验证码问题；如果只有带 Token 的业务接口 401，九成是 Token 的问题。第二，看响应体，服务端一般会返回 token expired、invalid signature 这类提示，直接指明了方向。
提示：401 是“没带有效凭证”，403 是“凭证有效但没权限”，两者排查方向完全不同，先分清再动手。
解码 Token，看 exp 过期时间
JWT 由 Header、Payload、Signature 三段组成，中间 Payload 里藏着过期时间 exp。把 Token 粘贴到在线 JWT 解码工具，直接看到 exp、签发时间 iat、签发方 iss。如果 exp 比当前时间小，结论明确：过期了，重新登录拿新 Token 即可。
注意 exp 是秒级时间戳（10 位），肉眼读不懂很正常，用时间计算工具换算成北京时间，一眼看出是“昨天过期”还是“下周才过期”。
注意：解码只读不验证签名，能看到过期时间，但“签名是否有效”要到下一步对照表确认，生产 Token 别贴到不可信的第三方网站。
5 种常见无效原因对照表
exp 没过期却依然 401，按这个表逐项排查，覆盖九成以上的联调翻车现场：
| 现象 | 原因 | 解法 |
|---|---|---|
| exp 已过期 | Token 自然过期 | 重新登录；长会话接 refresh_token 机制 |
| invalid signature | 密钥换了或串了环境 | 确认前后端密钥一致，测试/生产环境别混用 Token |
| 全接口 401、无提示 | 漏了 Bearer 前缀或多了换行空格 | Header 写成 Bearer <token>，复制时去掉首尾空白 |
| 刚签发就无效 | 前后端时钟差太大 | 服务端留几分钟时钟 skew，或对时后再试 |
| 部分接口 401 | aud/iss 与接口要求不符 | 对照接口文档检查受众和签发方字段 |
用 HTTP 工具复现验证
定位到原因后，用在线 HTTP 接口测试工具复现一遍：Header 加 Authorization: Bearer 你的Token，先发一次旧 Token 确认 401，再换新 Token 确认 200。把“复现—修复—验证”闭环走完，再回代码里改，避免改完靠猜。
GET /api/user/profile
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
→ 401 token expired：换新 Token 重发
→ 200：确认修复，收工
预防：刷新与统一处理
线上环境别让用户反复重新登录：access_token 设短有效期（如 2 小时），配 refresh_token 静默续期；前端封装统一的 401 拦截，发现过期自动刷新后重发请求，用户无感知。联调阶段把本文的对照表贴进接口文档，新人踩坑少一半。