Flask-JWT-Extended 是当前最稳妥的选择，因其官方维护、默认校验 exp/nbf、支持刷新令牌和自定义 claim，且避免手写 JWT 的安全疏漏。
为什么 Flask-JWT-Extended 是当前最稳妥的选择
Flask 官方不提供 JWT 支持，Flask-JWT 已停止维护且不兼容 Flask 2.0+；直接手写 JWT 签发/校验容易漏掉 exp 校验、时钟偏移、算法白名单等安全细节。用 Flask-JWT-Extended 能避免这些坑，它默认启用 HS256、自动验证 exp 和 nbf、支持刷新令牌和自定义 claim。
初始化应用时必须配置 SECRET_KEY 和 JWT_SECRET_KEY
这两个密钥不能混用：SECRET_KEY 用于 Flask session 等基础签名，JWT_SECRET_KEY 专用于 JWT 签名——若只设 SECRET_KEY 而没设 JWT_SECRET_KEY，启动时会抛出 RuntimeError: JWT_SECRET_KEY not set。生产环境必须用长随机字符串，别用 "my-secret" 这类硬编码值。
app.config["SECRET_KEY"] = "your-flask-session-key" # 可选，但建议设 app.config["JWT_SECRET_KEY"] = "your-jwt-signing-key" # 必须设，且长度 ≥32 字符
登录接口签发 token 的典型写法
不要在 create_access_token() 中传入原始密码或敏感字段；只放必要标识（如 user_id），其余信息应通过后续请求查库获取。token 默认有效期 15 分钟，可通过 expires_delta 调整，但别设过长（比如 30 天），否则无法主动失效。
- 用
create_access_token(identity=user_id)生成 access token - 若需刷新机制，再调用
create_refresh_token(identity=user_id) - 返回时把 token 放 JSON body 里（不是 header 或 cookie），前端自行存 localStorage
- 别在响应中设置
Set-Cookie——这违背“无状态”原则，也增加 CSRF 风险
@app.route("/login", methods=["POST"])
def login():
username = request.json.get("username")
password = request.json.get("password")
user = verify_user(username, password) # 自定义校验逻辑
if user:
access_token = create_access_token(identity=user.id)
return {"access_token": access_token}
return {"msg": "Bad username or password"}, 401保护路由时用 @jwt_required() 而不是手动解析 token
@jwt_required() 会自动从 Authorization: Bearer <token> 提取并校验 token，失败时直接返回 401；手动用 decode_jwt() 解析容易忽略签名验证、算法限制（如禁止 none 算法）、时间校验等关键步骤。另外，get_jwt_identity() 返回的是你当初传给 create_access_token() 的 identity 值，不是整个 payload。
立即学习“Python免费学习笔记（深入）”；
- 默认只校验 access token，刷新 token 需显式用
@jwt_required(refresh=True) - 若需额外 claim（如角色），用
get_jwt()获取完整 payload，从中读get_jwt()["role"] - 注意：Flask-JWT-Extended 不自动绑定用户对象，
get_jwt_identity()只返回 ID，查用户仍需你自己 DB 查询
实际部署时最容易被忽略的是时钟同步——如果服务器时间比 NTP 慢几秒，exp 校验就会失败，用户频繁收到 401；另一个是 token 存储位置，前端若把 token 放 cookie 且未设 HttpOnly，就可能被 XSS 窃取。这些都不是框架能兜底的。
