结论：cors配置不生效90%是中间件顺序错误或cors_allowed_origins与cors_allow_all_origins同时设置；corsmiddleware必须紧接在securitymiddleware等之前，且二者不可共存，带凭证时还需cors_allow_credentials=true、显式白名单及session_cookie_samesite='none'。
直接说结论：CORS 配置不生效，90% 是 CorsMiddleware 位置错了，或 CORS_ALLOWED_ORIGINS 和 CORS_ALLOW_ALL_ORIGINS 同时设了。
中间件顺序必须严格放在最前面
CorsMiddleware 不是“加进去就行”，它必须在所有能生成响应的中间件之前运行——包括 SecurityMiddleware、SessionMiddleware、CommonMiddleware，甚至 WhiteNoiseMiddleware（如果你用了）。否则，响应头根本加不上，浏览器看到的仍是原始响应。
- 错误写法：
'django.middleware.common.CommonMiddleware'在'corsheaders.middleware.CorsMiddleware'前面 - 漏掉中间件：只加了
'corsheaders'到INSTALLED_APPS，但没加CorsMiddleware到MIDDLEWARE - 类名拼错：
corsheaders.CorsMiddleware（少middleware.）或corsheaders.middleware.corsmiddleware（大小写错）
CORS_ALLOWED_ORIGINS 和 CORS_ALLOW_ALL_ORIGINS 不能共存
这两个配置互斥。如果同时设了 CORS_ALLOW_ALL_ORIGINS = True 和 CORS_ALLOWED_ORIGINS = ["http://localhost:3000"]，Django 会静默忽略白名单，只按 True 处理——生产环境等于裸奔。
- 开发用白名单：
CORS_ALLOWED_ORIGINS = ["http://localhost:3000", "http://127.0.0.1:5173"]，协议、域名、端口必须完全一致（http://localhost:3000≠http://localhost:3000/） - 需要模糊匹配时用
CORS_ALLOW_ORIGIN_REGEXES，例如[r"^https://.*\.myapp\.com$"] -
CORS_ALLOW_ALL_ORIGINS = True仅限本地调试，上线前必须删掉
带 Cookie 或认证头时必须配齐三要素
只要前端发请求加了 credentials: 'include'，后端就必须同时满足三个条件，缺一不可：
CORS_ALLOW_CREDENTIALS = True-
CORS_ALLOWED_ORIGINS显式列出源（不能用*，也不能开CORS_ALLOW_ALL_ORIGINS） -
SESSION_COOKIE_SAMESITE = 'None'且CSRF_COOKIE_SAMESITE = 'None'（否则 Django 会拒绝发送 Cookie）
最容易被忽略的是 SAMESITE='None' 这一步——很多人只配了 CORS_ALLOW_CREDENTIALS 和白名单，结果 Cookie 始终不随请求发出，前端反复 401。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
