核心在于服务端正确配置cors响应头以应对简单请求和预检请求：必须设置access-control-allow-origin、allow-methods、allow-headers、allow-credentials（需配具体域名）、max-age，并确保options方法被正确路由和响应。
REST接口开发中处理跨域请求（CORS），核心在于服务端正确响应浏览器的跨域检查，尤其要覆盖简单请求和预检请求两种场景。前端发请求时几乎不用改代码，关键配置全在后端。
明确哪些请求会触发CORS
不是所有跨域请求都一样：
- 简单请求：仅用 GET、HEAD、POST（且 Content-Type 限于 text/plain、application/x-www-form-urlencoded、multipart/form-data）——浏览器直接发，只加 Origin 头
- 非简单请求：PUT、DELETE、带自定义 Header（如 Authorization）、Content-Type 为 application/json 等——浏览器先发 OPTIONS 预检请求，确认通过才发真实请求
服务端必须返回的关键响应头
无论用什么语言框架，以下响应头缺一不可：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
Access-Control-Allow-Origin：指定允许的源，如
https://your-frontend.com；开发阶段可临时设为*，但若需携带 Cookie 或认证信息，就不能用*，必须写具体域名 -
Access-Control-Allow-Methods：列出允许的 HTTP 方法，如
GET, POST, PUT, DELETE, OPTIONS；注意一定要包含OPTIONS，否则预检失败 -
Access-Control-Allow-Headers：声明允许客户端发送的请求头，如
Authorization, Content-Type, X-Requested-With；如果前端发了自定义 Header，这里必须显式列出 -
Access-Control-Allow-Credentials：设为
true才允许前端传 Cookie 或 Authorization；此时Access-Control-Allow-Origin不能是* - Access-Control-Max-Age：缓存预检结果的时间（秒），避免重复 OPTIONS 请求，建议设为 3600 或更高
不同后端框架的典型配置方式
配置逻辑一致，写法略有差异：
-
Spring Boot：推荐用全局配置类，而不是在每个 Controller 加
@CrossOrigin；注册CorsConfiguration时确保路径匹配/**，并显式允许OPTIONS方法 -
Express（Node.js）：使用
cors中间件，传入对象参数，例如：{ origin: 'https://your-frontend.com', credentials: true, exposedHeaders: ['X-Total-Count'] } -
FastAPI：用
CORSMiddleware，注意allow_origins和allow_credentials=True不能共存于['*']，必须列明具体域名 -
Django REST Framework：安装
djangorestframework-cors，在settings.py中配置CORS_ALLOWED_ORIGINS并启用中间件
调试时重点看网络面板里的 OPTIONS 请求
遇到跨域失败，别只盯着主请求：
- 打开浏览器开发者工具的 Network 标签页，筛选
OPTIONS请求 - 检查它的响应状态是否为 200，响应头里是否有上面提到的几个
Access-Control-*字段 - 如果 OPTIONS 返回 404、405 或缺少必要头，说明服务端没正确处理预检——常见于路由未覆盖 OPTIONS 方法，或反向代理（如 Nginx）拦截了 OPTIONS 请求
- 再看主请求的 Request Headers 是否含
Origin，Response Headers 是否返回了匹配的Access-Control-Allow-Origin
