Session 在 Flask/Django 中越来越难用，因其依赖服务端存储、扩容受限、跨域/移动端下 Cookie 易失效；JWT 更适合 API 场景，核心优势是可验证而非无状态，但需合理设计刷新与失效机制。
session 在 Flask/Django 里为什么越来越难用
因为 session 默认依赖服务端存储（如 Redis 或文件），要扩容就得加 sticky session 或共享存储，而无状态服务编排（比如 K8s 水平扩缩）天然排斥它。更麻烦的是，跨域、移动端、微前端场景下，Set-Cookie 被拦截或失效太常见——你看到 401 不是因为没登录，而是 session ID 根本没发过去。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 别在 API 服务里默认开
SESSION_COOKIE_HTTPONLY=True（尤其要支持跨域调用时），否则前端拿不到document.cookie，但又不能简单关掉——得配合SameSite=None; Secure和 HTTPS - Django 的
SESSION_ENGINE切到django.contrib.sessions.backends.cache只是缓解，不是解法；缓存丢失 = 登录态消失，比数据库还脆 - Flask-SQLAlchemy 配 session 存 DB？别，单次登录写一次 DB，QPS 上千就成瓶颈，且无法做分布式校验
token（JWT）不是银弹，但适合 API 场景
JWT 的核心优势不是“无状态”，而是“可验证”：服务端不查库，只验签名 + 过期时间，适合网关层统一鉴权。但它也带来新问题——比如没法主动失效（revoke），刷新逻辑写错就变成永久凭据。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
access_token用短生命周期（15–30 分钟），refresh_token单独存 DB 或 Redis，带user_id + jti + created_at，每次刷新都换新refresh_token - 别把敏感字段塞进 JWT payload：
is_admin可以，password_hash或email不行——JWT 是 Base64 编码，不是加密 - PyJWT 默认不校验
nbf（not before）和aud（audience），要用jwt.decode(..., options={"require_nbf": True, "require_aud": True})
什么时候该混用 session + token
典型场景是：Web 管理后台（需要 CSRF 防护、表单提交友好）用 session，同时提供 REST API 给内部系统调用（比如定时任务脚本、数据同步服务），这时给 API 路由单独走 token 认证更干净。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- Flask 中用
@app.before_request判断请求头是否有Authorization: Bearer xxx，有则走 JWT 解析，无则 fallback 到session.get("user_id") - Django 用
AuthenticationBackend实现双模式：继承ModelBackend，重写authenticate，先试request.META.get("HTTP_AUTHORIZATION")，再试request.session.get("_auth_user_id") - 避免在同一个接口里既读
session又解析access_token——逻辑耦合，调试时分不清是谁在设用户态
CSRF、XSS、token 存储位置的真实取舍
很多人以为 “token 存 localStorage 就 XSS 危险，存 httpOnly cookie 就 XSRF 危险”，其实关键不在存哪，而在怎么用。现代 SPA 架构下，token 存内存（useState 或 ref）+ 每次请求手动塞 header，反而最安全——只要页面不被 XSS 注入，token 就不会泄露；而服务端校验 Origin 和 Referer 能防大部分 CSRF。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 别用
localStorage.setItem("token", ...)—— 页面任意一处 XSS 都能直接盗走 - 如果必须用 cookie 存 token，务必设
HttpOnly=False+Secure=True+SameSite=Lax（登录页 POST 后跳转可用），但后端必须校验Origin头 - JWT 的
iss字段建议填具体域名（如"https://api.example.com"），不是泛域名，防止 token 被误用于测试环境
真正的复杂点不在选 session 还是 token，而在于你是否清楚每个 HTTP 请求的来源、传输路径、终止位置——浏览器插件、代理、CDN、网关、服务网格，每一层都可能吞掉 header、改写 cookie、缓存响应。漏掉其中一环，安全模型就塌一半。
