JWT才是容器化、多实例或无状态环境下更省事、更少出错的选择；因其无需共享存储、不依赖Cookie、可减少数据库查询，但在需实时踢人时仍需配合黑名单机制。
不是“应优先选择”，而是——当你的 Python Web 服务部署在容器化、多实例或无状态环境（比如用 uvicorn + gunicorn 跑多个 worker，或用 Kubernetes 编排），JWT 才是更省事、更少出错的选择。Session 在单机 Flask/Django 开发时够用，但一旦涉及横向扩展，它立刻变成运维负担。
分布式部署下 Session 的共享成本太高
Session 默认存在内存里，多进程/多实例时，用户 A 登录到实例 1，下次请求被负载均衡打到实例 2，session.get("user_id") 就是 None。强行解决？得引入 Redis 或 Memcached，还要配连接池、超时、序列化方式（flask-session 的 SESSION_TYPE 配错一个值，session 就静默失效）。而 JWT 只需验证签名，PyJWT.decode(token, key, algorithms=["HS256"]) 这一行代码，在任意实例上都有效。
CSRF 和 Cookie 依赖让 Session 在 API 场景中处处受限
Gradio、FastAPI REST 接口、前后端分离的 Vue/React 前端，都不想管 Set-Cookie、SameSite、Secure 这些细节。Session 强绑定 Cookie，跨域请求默认被浏览器拦截；你得手动开 CORS、配 credentials=True、前端传 withCredentials，稍一漏，401 就报给你看。JWT 可以走 Authorization: Bearer <token>，不碰 Cookie，天然绕过这些坑。
JWT 的 payload 能减少数据库查询，但别往里塞敏感字段
Session 每次都要查 DB 或缓存拿用户角色、权限；JWT 的 payload 可以直接带上 {"user_id": 123, "role": "admin", "scopes": ["read:log"]}，后端校验完签名就能用。但注意：payload 是 base64 编码，不是加密——password_hash、api_key 绝对不能放进去；过期时间（exp）必须设，否则 token 永不过期，撤回只能靠黑名单（又回到有状态逻辑）。
立即学习“Python免费学习笔记（深入）”；
真正容易被忽略的点：JWT 不是银弹。如果你的应用需要实时踢人（比如管理员强制登出某设备），JWT 本身做不到——它没状态，你得额外维护一个 revoked_tokens 表或 Redis 集合，反而比 Session 更重。这时候，该用 Session 就用 Session，别硬套 JWT。
