不能直接用flask-login因依赖session/cookie，而前后端分离时跨域导致cookie不可靠；jwt无状态，由前端通过authorization头携带，更适配分离架构。
为什么不能直接用 flask-login 做前后端分离认证
因为 flask-login 依赖 session 和 cookie，而前后端分离时前端（比如 Vue/React）通常不共享后端域名下的 cookie，或明确禁用第三方 cookie（尤其在 Safari 和 iOS 上），session 根本无法可靠传递。JWT 是无状态的，token 存在 localStorage 或 Authorization header 里，由前端主动携带，绕过了 cookie 限制。
PyJWT 和 flask-jwt-extended 该怎么选
直接用 PyJWT 手写签发、校验、刷新逻辑容易出错（比如没验证 exp、漏掉 iat 检查、密钥硬编码、没处理 token 黑名单）。flask-jwt-extended 封装了标准流程，提供 @jwt_required()、create_access_token()、自动刷新机制，还支持 access/refresh 双 token 模式——这是生产环境必需的。
- 用
flask-jwt-extended：安装pip install flask-jwt-extended，初始化时必须设置JWT_SECRET_KEY（别用默认字符串，用secrets.token_urlsafe(32)生成） - access token 过期时间建议设短（如 15 分钟），refresh token 过期设长（如 7 天），且 refresh token 必须存服务端（如 Redis）做可撤销控制
- 不要把用户密码、手机号等敏感字段塞进 JWT payload——只放
user_id或identity，其他信息由后端接口按需查库
如何让前端正确携带 JWT 并避免 XSS/CSRF 混淆
前端必须把 token 放在请求 header 的 Authorization: Bearer <token></token> 中，而不是 query string 或 body。Flask-JWT-Extended 默认只从 header 读取，不支持 cookie 方式（除非显式配置 JWT_TOKEN_LOCATION = ['cookies']，但这又回到有状态陷阱）。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- Vue Axios 示例：
axios.defaults.headers.common['Authorization'] = 'Bearer ' + localStorage.getItem('access_token') - React fetch 示例：
headers: { 'Authorization': 'Bearer ' + token } - 千万别把 token 存在
document.cookie且未设HttpOnly——这等于给 XSS 开门 - JWT 本身不防 CSRF，但因为不用 cookie，天然规避了传统 cookie-based CSRF；若你非要用 cookie 存 token，请务必配
SameSite=Strict和Secure
刷新 token 时为什么总遇到 ExpiredSignatureError 或 InvalidHeaderError
常见原因是前端传错了 header 格式，或者后端没配对 refresh token 的 secret 和算法。Flask-JWT-Extended 默认用同一个 JWT_SECRET_KEY 签发 access 和 refresh token，但你可以用 JWT_REFRESH_SECRET_KEY 单独设 refresh 密钥（更安全）。
- 确保刷新接口路由用
@jwt_refresh_token_required()（新版本是@jwt_required(refresh=True)） - 检查前端是否把 refresh token 当成 access token 发到了 /login 接口，或反过来
- Redis 中存储 refresh token 时，key 应为
refresh:{jti}，value 可存用户 ID 和过期时间，校验前先查是否存在 - 调用
create_access_token(identity=xxx)时，不要传fresh=True——那是用于敏感操作（如改密码）的二次确认，不是刷新场景
JWT 不是银弹：它解决了会话状态解耦，但也把 token 存储、过期管理、吊销复杂度甩给了前端和运维。真正难的不是签发 token，而是让 refresh 流程在各种网络异常、多标签页、token 被劫持后仍保持安全边界。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
