Django跨域资源共享(CORS)问题详解与解决方案

阿麦

发布时间：2026-10-13| 5人浏览过

原创

本文深入解析Django前后端分离开发中常见的CORS跨域问题。详细区分简单请求与非简单请求（预检请求）机制，解析OPTIONS请求及关键响应头含义，并展示如何通过安装配置django-cors-headers库快速解决跨域访问限制，确保后端接口安全且高效地被前端调用。

Django跨域问题背景

在近期进行的前后端分离Web项目开发中，我负责后端部分，技术栈选用Django框架。在前后端集成测试阶段，遇到了涉及Web安全机制的问题，其中跨域资源共享（CORS）便是典型代表。

CORS机制解析

CORS问题概述

跨域资源共享（CORS）是一种基于额外HTTP头的安全机制，旨在允许运行在特定源（域名）上的Web应用，被授权访问来自不同源服务器的指定资源。当资源请求发起自与资源本身所在服务器不同的域、协议或端口时，即构成跨域HTTP请求。CORS机制通过允许Web应用服务器实施跨域访问控制，实现了安全的数据跨域传输。现代浏览器在API容器中使用CORS，有效降低了跨域HTTP请求带来的潜在风险。

域的判定标准由协议、主机名和端口号共同决定。简而言之，若两个URL在协议、主机或端口中任意一项存在差异，则它们属于不同的域，彼此间的访问将触发跨域限制。

在我的项目环境中，前端部署地址为 http://localhost:8001 ，后端API地址为 http://localhost:8000 。尽管两者的协议和主机名一致，但端口号不同，导致前端调用后端接口时必然遭遇跨域访问限制。

简单请求与非简单请求

简单请求机制

简单请求不会触发跨域预检流程，需同时满足以下条件：

请求方法必须为以下之一：

GET HEAD POST

请求头字段集合需仅包含以下类型：

Accept
Accept-Language
Content-Language
Content-type 仅限 text/plain 、 multipart/form-data 或 application/x-www-form-urlencoded
DRP
DownLink
Save-Data
Viewport-Width
Width

非简单请求处理

不满足简单请求条件的请求被视为非简单请求。此类请求在发送实际数据前，必须先发送一个预检请求（Preflight Request），HTTP方法为 OPTIONS。预检请求旨在防止跨域操作对服务器用户数据造成未预期的影响。若请求满足以下任一条件，则必须首先发送预检请求：

使用了以下HTTP方法之一：

PUT DELETE CONNECT OPTIONS TRACE PATCH

请求头中包含非简单请求允许的头部字段。

Django中的CORS解决方案

Django开发中的具体实践

在后端开发过程中，我遇到了上述跨域场景。

错误日志显示请求被CORS协议拦截。

响应中的 Origin 字段标识了请求源地址，请求使用了 OPTIONS 方法，目标 Host 指向本机地址。服务器返回了响应，但并未执行实际的业务请求。

为解决此问题，我搜索相关方案后，安装了 django-cors-headers 库并完成配置。在配置过程中，我将该中间件置于Django中间件列表的首位。再次访问相同地址，结果如下：

1. 首先，浏览器检测访问请求头，发现存在CORS安全头部集合之外的字段，因此向服务器发送预检请求。从上图可见，方法为 OPTIONS，该方法对服务器资源无副作用。请求头中的 Access-Control-Request-Method 字段表明实际业务请求将采用 GET 方法， Origin 字段表示请求源，将在服务器端进行验证。

2. 验证通过后，服务器会在响应头中添加特定字段返回，各字段含义如下：