JavaScript跨域由浏览器同源策略限制，前端无需处理CORS逻辑，只需正常发起fetch/XHR请求；关键在后端配置Access-Control-Allow-Origin等响应头，且需区分简单请求与预检请求（OPTIONS）并正确响应。
JavaScript 中用 Ajax 处理跨域问题，前端本身不“解决” CORS，而是依赖后端正确配置响应头；浏览器自动检查并放行或拦截，你只要按正常方式写 fetch 或 XMLHttpRequest 即可。
理解跨域限制的真正来源
跨域不是前端代码的问题，而是浏览器同源策略（协议、域名、端口三者必须完全一致）施加的安全限制。只要请求目标与当前页面不同源，浏览器就会介入——它不会阻止请求发出，但会拦截响应，除非服务端在返回中明确声明允许。
关键点：
- 浏览器自动判断是否跨域，无需前端加判断逻辑
- 前端发请求时，浏览器悄悄带上
Origin请求头 - 服务端必须在响应中返回合法的
Access-Control-Allow-Origin等字段，浏览器才把响应交给 JavaScript
区分简单请求和预检请求（OPTIONS）
浏览器对两类跨域请求处理方式不同，直接影响后端要配哪些头：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
-
简单请求：方法是 GET/HEAD/POST，且
Content-Type是text/plain、application/x-www-form-urlencoded或multipart/form-data。只需后端返回Access-Control-Allow-Origin即可 -
非简单请求：比如用
PUT、DELETE，或带Authorization、X-Token等自定义 header，或发送 JSON（Content-Type: application/json）。浏览器会先发一个OPTIONS预检请求，后端必须响应成功，并返回完整 CORS 头，主请求才会发出
常见踩坑：前端无意识加了 headers: { 'Authorization': 'Bearer xxx' }，就把一个简单 POST 变成了非简单请求，而服务端没配 OPTIONS 响应，结果请求直接失败。
后端必须返回的核心响应头
这些头由服务端设置，前端不能伪造或覆盖。典型组合如下：
-
Access-Control-Allow-Origin：必填。开发可用http://localhost:5173；生产环境避免用*，尤其涉及凭证时 -
Access-Control-Allow-Methods：如GET, POST, PUT, DELETE；不能只写* -
Access-Control-Allow-Headers：列出前端实际发送的额外 header，比如Authorization, X-Request-ID -
Access-Control-Allow-Credentials：设为true才能传 Cookie 或 token；此时Access-Control-Allow-Origin必须指定具体域名，不能是* -
Access-Control-Expose-Headers：若前端需读取响应里的自定义 header（如X-Rate-Limit），后端必须在这里显式声明
前端配合要点与常见写法
前端唯一要做的，是确保请求方式不意外触发更严格的校验：
- 不带凭证的普通请求：直接
fetch('/api/data')，不用额外配置 - 需要 Cookie 或认证信息：fetch 中加
credentials: 'include'，同时后端必须配Access-Control-Allow-Credentials: true和明确的Origin - 发 JSON 数据：
fetch('/api/save', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(data) })—— 这属于非简单请求，务必确认后端支持 OPTIONS 并返回全部必要头 - 调试建议：打开浏览器开发者工具的 Network 面板，查看请求的 Response Headers 是否包含上述 CORS 字段，再看 Preview 或 Response 是否有内容
