cors配置不生效主因是中间件顺序错误或源匹配规则不当：corsmiddleware必须置于最前（securitymiddleware、sessionmiddleware、commonmiddleware之前），且cors_allowed_origins与cors_allow_all_origins不可共存；带凭证请求需同时满足cors_allow_credentials=true、显式白名单及samesite=none等三要素。
CORS 配置不生效，90% 是中间件顺序或源匹配规则写错了。
corsheaders.middleware.CorsMiddleware 必须放在最前面
它需要在 CommonMiddleware、SecurityMiddleware 甚至 SessionMiddleware 之前运行，否则响应头根本加不上。浏览器看到的仍是原始响应，CORS 就形同虚设。
常见错误写法：
- 把
CorsMiddleware放在CommonMiddleware后面 - 漏掉
CorsMiddleware，只加了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 处理 —— 这在生产环境极其危险。
开发时建议用白名单：
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 或认证头时必须配全三要素
只要前端发请求时加了 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是否包含实际用到的方法，例如["GET", "POST", "PATCH", "DELETE", "OPTIONS"] -
CORS_ALLOW_HEADERS是否覆盖前端发的 header，比如"authorization"、"x-requested-with"、"content-type"
注意：CORS_ALLOW_HEADERS 默认不含 "authorization"，必须手动加进去，否则 OPTIONS 返回 403。
最易被忽略的是：CORS 配置只对响应头起作用，它不改变 Django 自身的权限逻辑或 CSRF 校验。如果你同时用了 @csrf_exempt，那是另一层控制，和 CORS 无关 —— 别混为一谈。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
