jwt.decode(token, key=SECRET, algorithms=['HS256'],
options={'require': ['exp','sub']})
网关里的校验代码写着 jwt.decode(token, options={'verify_signature': False})，把 payload 里的 sub 从 1001 改成 1002，接口照样返回 200，拿到的是别人的资料。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，解码和验签是两个动作，前者只做 Base64 拆分，谁都能做。代码为了省事关掉验签，token 就退化成一个明文 JSON，改完重新编码即可。这种错误上线后从日志上看不出异常。
「JWT 跳过签名校验」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。改完隔一天再看一次，当场正常不代表能稳住。
测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
处理上按这个顺序：统一封装一个验签方法 业务代码只能调这个方法；算法写死成固定值 不接受 token 头里的 alg；验签失败直接 401 不要降级放行；在测试里放一条改 payload 的用例 断言必须是 401。
改完只确认一件事：把 sub 改掉再请求返回 401 错误是 signature verification failed 正常 token 仍然 200。