JWT 解析
只是解码，不验证签名——所以别用它判断 token 是否合法，只用来看里面装了什么。
三个部分
JWT 由 header.payload.signature 三段组成，前两段是 Base64URL 编码的 JSON（可读），第三段是签名。这里只解前两段，没有密钥无法验证签名。
什么时候用
- 接口返回 401，先确认 exp 是不是已经过去、iat 与本机时间差了多少分钟，把「token 过期」这一类原因排除掉，再动代码。
- 想知道服务端实际下发了哪些 claim（scope、roles、aud、自定义字段），以及 header 里的 alg 和 kid 是什么，比翻文档和猜字段名快得多。
什么时候不用
- 要判断 token 是否可信、有没有被改过：解码只是 Base64URL 还原，任何人都能改 payload 再拼回去，必须由服务端用密钥或 JWKS 公钥验签。
- 要拿解码出的 roles、scope 在前端做权限判断：这些字段未经验证，改一个字母就能提权，权限只能由服务端验签后决定，前端最多用来隐藏入口。
限制与隐私
解码在浏览器本地完成，token 不上传、不写日志、不发请求。限制：不验签，也不校验 alg、iss、aud 或吊销；只支持三段式 JWS，JWE 不支持；有效期按本机时钟计算，可能偏差；生产 token 只在可信页面解析。
常见问题
把 JWT 粘进来安全吗？
相对安全，但有前提。解码在页面的 JavaScript 里完成，不上传、不写日志、不发请求，刷新即清空。风险在页面之外：浏览器扩展、被注入的第三方脚本、共用电脑的剪贴板与历史，都可能拿到它。线上环境的 access token 等同于密码，排查时尽量用测试环境的假 token；必须解析真实 token 时，先确认页面来源可信，用完点清空。
不验证签名，这个结果还能当什么用？
只能当「读内容」用：看结构、看 claim、看时间戳。它无法证明 token 由谁签发、有没有被吊销、是不是伪造的。任何安全决策——放行、授权、解密——都必须在服务端验签并校验 exp、nbf、iss、aud 之后做。页面上显示的「有效」只是本机时钟下的一次减法，不代表服务端会接受。
exp 还没到，接口却返回 401，为什么？
常见四种：一是本机时钟偏了几分钟，卡在 nbf 或 exp 的边界上；二是服务端吊销了 token 或轮换了密钥（JWT 无状态，吊销只能靠黑名单或短有效期）；三是 aud、iss 不匹配，或 token 类型不对（把 id_token 当 access_token 用）；四是网关与业务服务的时钟不一致。解码只能帮你排除跟时间有关的那几类。