Django跨域问题解决教程

本文深入解析了 Django 项目中使用 django-cors-headers 解决跨域问题的常见陷阱与最佳实践，直击“装了却仍返回 403”的核心症结——中间件 CorsMiddleware 必须紧邻 SecurityMiddleware 置于 MIDDLEWARE 链靠前位置（通常第2位），否则 CORS 响应头根本无法写入；同时系统梳理了开发环境快速放开限制（CORS_ALLOW_ALL_ORIGINS=True）、生产环境精准配置白名单（注意协议/域名/端口完整匹配、禁用路径与通配符）、预检请求（OPTIONS）失败的根源（缺失允许方法、CSRF 干扰、DRF 权限拦截）以及反向代理覆盖响应头等高频痛点，为前后端联调和线上部署提供可落地、避坑的全链路配置指南。

为什么装了 django-cors-headers 还是 403？

根本原因是：Django 默认只允许同源请求，而 django-cors-headers 不是“开个开关就完事”的中间件——它必须被正确插入到 MIDDLEWARE 列表中，并且位置很关键。常见错误是把它放在 SessionMiddleware 或 CommonMiddleware 之后，导致 CORS 头没被写入响应。

正确做法是：把它紧挨着 SecurityMiddleware 放在中间件链靠前位置（通常第2或第3位），确保它有机会处理所有响应。

• INSTALLED_APPS 中添加 'corsheaders'
• MIDDLEWARE 中插入位置示例：

  ['django.middleware.security.SecurityMiddleware',
   'corsheaders.middleware.CorsMiddleware',  # ← 必须在这儿，不能靠后
   'django.contrib.sessions.middleware.SessionMiddleware',
   ...]

• 漏掉 CorsMiddleware 的类名拼写（比如写成 CorsHeadersMiddleware）会静默失败，Django 不报错但不生效

开发环境允许所有前端域名，怎么配最简单？

仅限本地开发（如前端跑在 http://localhost:3000），直接放开限制最快：

• 设置 CORS_ALLOW_ALL_ORIGINS = True（Django ≥ 3.1 + django-cors-headers ≥ 3.7.0）
• 旧版本用 CORS_ORIGIN_ALLOW_ALL = True（已弃用，但仍有效）
• 务必确认没同时设置 CORS_ORIGIN_WHITELIST 或 CORS_ALLOWED_ORIGINS，否则会覆盖 ALLOW_ALL
• 如果前端用的是 file:// 协议（比如直接双击 HTML 文件），浏览器会拒绝发送 Origin 头，CORS 中间件收不到请求头，自然不响应——这不是配置问题，是浏览器策略，必须走 HTTP 服务

生产环境必须精确控制来源，CORS_ALLOWED_ORIGINS 怎么填？

填错格式会导致 403 或完全不响应 CORS 头。注意三点：

• 值是列表，不是字符串：CORS_ALLOWED_ORIGINS = ['https://myapp.com', 'https://admin.myapp.com']
• 协议、域名、端口（如有）必须完整匹配，http://myapp.com 和 https://myapp.com 是两个不同源
• 不要带路径（/api）、尾部斜杠（https://myapp.com/）或通配符（https://*.myapp.com）——这些都不支持，会直接拒绝
• 如果前端部署在 CDN 或反向代理后，检查实际到达 Django 的 Origin 请求头是什么（可能被代理改写），而不是你“以为”的地址

POST/PUT/DELETE 请求预检失败（OPTIONS 405 或 500）？

浏览器对非简单请求（如带 Content-Type: application/json 的 POST）会先发 OPTIONS 预检。常见卡点：

• Django 默认路由不处理 OPTIONS 方法，需确保视图函数或 DRF 的 APIView 显式支持，或全局加 CORS_ALLOW_METHODS
• CORS_ALLOW_METHODS = ['GET', 'POST', 'PUT', 'PATCH', 'DELETE', 'OPTIONS']（缺 OPTIONS 就会 405）
• 如果用了 CSRF 保护（默认开启），而前端又没传 X-CSRFToken，Django 会在预检后拒绝主请求——开发阶段可临时关掉 django.middleware.csrf.CsrfViewMiddleware，生产环境应配合 CORS_ALLOW_CREDENTIALS = True + 前端携带凭证
• DRF 用户注意：DEFAULT_PERMISSION_CLASSES 若含 IsAuthenticated，OPTIONS 请求也会被权限拦截，建议对预检放行或改用 AllowAny 权限类

实际部署时最容易忽略的，是 Nginx/Apache 等反向代理层可能吞掉或覆盖 Access-Control-Allow-Origin 响应头。如果确认 Django 日志里已输出 CORS 头，但浏览器 Network 面板看不到，先查代理配置。

以上就是《Django跨域问题解决教程》的详细内容，更多关于的资料请关注golang学习网公众号！