不止于登录注销：基于 Session 与 JWT 的无状态/有状态认证实战

更多内容请见： 《Python Web项目集锦》 - 专栏介绍和目录

在绝大多数 Django 开发者的认知里，认证似乎就是request.user和@login_required。只要调用了login()，用户就“登录”了；调用了logout()，用户就“注销”了。这层看似简单的抽象背后，隐藏着互联网认证体系最核心的架构博弈：有状态与无状态的较量。

随着现代应用从传统的单体 Web 演进为多端（Web、App、小程序）并存、微服务解耦的架构，仅仅知道如何调用 Django Auth API 已经无法应对复杂的业务场景。Session 跨域共享怎么做？JWT 为什么无法简单注销？动静混合架构下如何保证认证一致性？

本文将深入 Django 认证体系的底层机制，从源码级别剖析 Session 与 JWT 的运行原理，并给出在企业级高并发、多终端场景下的实战策略。

第一章：剥开抽象的皮——HTTP 无状态与认证的本质

要理解认证，首先要回到 HTTP 协议的起点：HTTP 是无状态的。
服务器处理完一次请求后，会立刻忘记你是谁。为了在无状态的协议上构建有状态的应用（比如购物车、用户中心），必须引入