cors配置不生效主因是中间件顺序错误或源匹配规则不当：corsmiddleware必须置于middleware最前，且cors_allowed_origins与cors_allow_all_origins不可共存；带凭证请求需同时满足cors_allow_credentials=true、显式源列表及samesite=none配置。
CORS 配置不生效，90% 是中间件顺序或源匹配规则写错了。
corsheaders.middleware.CorsMiddleware 必须放在 MIDDLEWARE 最前面
它需要在 SecurityMiddleware、SessionMiddleware、CommonMiddleware 之前运行，否则响应头根本加不上。浏览器看到的仍是原始响应，CORS 就形同虚设。
- 常见错误写法：把
corsheaders.middleware.CorsMiddleware放在CommonMiddleware后面 - 漏掉
corsheaders.middleware.CorsMiddleware，只加了'corsheaders'到INSTALLED_APPS - 用错类名，比如写成
corsheaders.CorsMiddleware（少中间的middleware.）
正确顺序示例：
['corsheaders.middleware.CorsMiddleware', 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware',]
CORS_ALLOWED_ORIGINS 和 CORS_ALLOW_ALL_ORIGINS 不可共存
这两个配置互斥。如果同时设置 CORS_ALLOW_ALL_ORIGINS = True 和 CORS_ALLOWED_ORIGINS = []，Django 会静默忽略后者，只按 True 处理——这在生产环境极其危险。
Django Unfold
下载
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
- 开发时建议用白名单：
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$"]
带 Cookie 或 Authorization 请求必须配全三要素
只要前端发请求时加了 credentials: 'include'，后端就必须同步满足三个条件，缺一不可：
CORS_ALLOW_CREDENTIALS = True-
CORS_ALLOWED_ORIGINS不能是*或CORS_ALLOW_ALL_ORIGINS = True（必须显式列出源） -
SESSION_COOKIE_SAMESITE = 'None'且CSRF_COOKIE_SAMESITE = 'None'（否则 Django 会拒绝发送 Cookie）
漏掉任一配置，浏览器会静默丢弃响应，控制台只显示 “CORS error”，不报具体原因。
OPTIONS 预检失败通常因为方法或头没放行
当请求含自定义 header（如 Authorization）或非简单方法（如 PATCH），浏览器先发 OPTIONS 请求。若失败，大概率是以下配置缺失：
-
CORS_ALLOW_METHODS没包含实际使用的动词，例如漏了'PATCH'或'OPTIONS' -
CORS_ALLOW_HEADERS没覆盖前端传的 header，比如少了'authorization'或'x-requested-with' -
CORS_PREFLIGHT_MAX_AGE过小导致频繁预检，但一般不是失败主因
最易被忽略的是：即使你只用 GET，只要加了 Authorization 头，就触发预检——这时候 CORS_ALLOW_HEADERS 必须显式包含它。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
