jwt防护失效的三大关键错误：不设algorithm参数、不校验refresh_token状态、exp未转为utc整型时间戳；任一缺失均导致签名形同虚设。
直接说结论：不设 algorithm 参数、不校验 refresh_token 状态、用 datetime.now() 生成 exp，这三件事做错任意一件，JWT 就算“签了名”也等于没防护。
PyJWT encode() 必须显式传 algorithm 参数
新版 PyJWT（2.0+）已禁用默认算法，jwt.encode(payload, key) 会直接报 TypeError: encode() missing 1 required argument: 'algorithm'。这不是警告，是硬性拦截——但很多旧教程还在教“省略参数”，导致本地能跑、上线就崩。
常见错误场景：
- 复制示例时漏掉
algorithm="HS256"，只写jwt.encode(payload, secret) - 误用
algorithm="none"做调试，部署时忘记改回来，生成无签名 token - 密钥从环境变量读取但拼错变量名（如
os.getenv("JWT_SECRET")实际是JWT_SECRET_KEY），导致key=None，触发 none 算法回退
实操建议：
- 永远显式写全：
jwt.encode(payload, secret_key, algorithm="HS256") - 对称加密用
HS256足够，密钥长度 ≥32 字节（secrets.token_urlsafe(32)生成） - 别在代码里写死
"secret"，哪怕只是临时测试——PyJWT 不会报错，但攻击者一抓一个准
refresh_token 必须查库 + 即时作废
刷新不是“拿旧 refresh_token 换新 access_token”，而是服务端要确认：这个 refresh_token 没被用户登出、没被管理员踢出、没过期、且属于当前用户。只校验签名和 exp 是典型漏洞。
典型错误：
- 把 refresh_token 当 access_token 一样无状态校验，不查数据库/Redis
- 查库后没立即更新原记录的
is_revoked=True，导致同一 refresh_token 可重复使用多次 - 存明文 refresh_token 到数据库，一旦库泄露，所有账户永久失守
实操建议：
- 存储前先哈希：
token_hash = hashlib.sha256(refresh_token.encode() + SECRET_KEY.encode()).hexdigest() - 数据库字段至少含：
token_hash（唯一索引）、user_id、expires_at（UTC 时间戳）、is_revoked - 验证通过后第一件事：执行
UPDATE tokens SET is_revoked = TRUE WHERE token_hash = %s，再生成并返回新 refresh_token
时间戳必须用 UTC，且 exp 要转成 int
exp 字段在 JWT 标准里要求是 Unix 时间戳（整数秒），不是 datetime 对象。用 datetime.now() 或没调 int() 转换，会导致 PyJWT 在 decode 时抛 TypeError 或静默失败。
容易被忽略的坑：
-
datetime.now() + timedelta(minutes=15)返回本地时区时间，部署到美国服务器就提前 8 小时过期 -
"exp": datetime.utcnow() + timedelta(minutes=15)是 datetime 对象，PyJWT 2.x 默认拒绝（除非关 strict 模式） - 手动构造 payload 时写
"exp": "1732782345"（字符串），PyJWT 不自动转 int，校验直接失败
实操建议：
- 统一用：
"exp": int((datetime.utcnow() + timedelta(minutes=15)).timestamp()) - 或者更稳妥：
"exp": datetime.utcnow().replace(tzinfo=timezone.utc) + timedelta(minutes=15)（PyJWT 会自动转 int） - 所有时间相关字段（
iat、nbf、exp）都走 UTC，别信服务器时区设置
前端重试逻辑必须加锁 + 分离处理
后端刷新接口返回 401 时，前端若无脑重发 /auth/refresh，会瞬间打爆接口，还可能触发风控限流。真正的问题不在“怎么发请求”，而在“谁来管并发和失败兜底”。
真实崩溃点：
- 多个请求同时 401，全部进刷新队列，结果只成功一个，其余卡在 pending 状态
- /auth/refresh 自身返回 401（比如 refresh_token 已被 revoke），前端没单独判断，继续重试 → 死循环
- 用
async/await顺序重发原始请求，丢失了原始请求的 headers/body 上下文
实操建议：
- 全局维护一个
isRefreshing: boolean标志位，true 时后续 401 全部挂起，等新 token 返回后统一重放 - /auth/refresh 的响应必须单独处理：若 status ≥ 400，立刻清空 localStorage 中所有 token 并跳登录页，不重试
- 缓存原始请求用 Promise 队列，不是重发，是等新 token 到手后，用新 header 重新 fetch 原始 URL + 原 body
最常被绕开的细节：refresh_token 绝不能放 Authorization Header 传，必须走独立接口 + HttpOnly Cookie（配 SameSite=Strict 和 Secure），否则 XSS 一偷一个准。而 access_token 就该走 Header——短命 + 可废止，这才是设计本意。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
