JavaScript不处理CORS，由浏览器执行同源策略并自动处理预检，后端必须正确配置Access-Control-Allow-Origin等响应头，前端只需正常发请求。
JavaScript 本身不“处理”跨域资源共享（CORS）问题，而是依赖浏览器与后端协同完成。前端只需按正常方式发请求，关键在后端正确返回响应头。浏览器自动判断是否跨域、是否预检、是否放行响应——你写的 fetch 或 XMLHttpRequest 不需要为 CORS 加额外逻辑。
理解谁该做什么
跨域限制来自浏览器同源策略（协议、域名、端口三者必须完全一致），不是 JavaScript 的缺陷，也不是前端能绕开的规则。它只作用于脚本发起的网络请求（如 fetch/AJAX），不影响 <img>、<script>、<link> 等资源加载。
- 前端：照常写请求，比如
fetch('/api/user')；若需带 Cookie 或 token，加{ credentials: 'include' } - 浏览器：自动添加
Origin请求头，拦截不合规响应，对非简单请求先发 OPTIONS - 后端：必须返回合法 CORS 响应头，否则响应永远到不了 JS 代码里
区分简单请求和预检请求
是否触发预检（OPTIONS 请求），取决于你发的请求是否“简单”。这直接影响后端要配哪些头：
-
简单请求：方法是 GET/HEAD/POST，且
Content-Type是text/plain、application/x-www-form-urlencoded或multipart/form-data。后端只需返回Access-Control-Allow-Origin即可 -
非简单请求：比如用 PUT/DELETE、发送 JSON（
Content-Type: application/json）、带Authorization或自定义 header（如X-Request-ID）。浏览器会先发 OPTIONS，后端必须响应成功，并返回完整 CORS 头，主请求才发出
常见踩坑：前端无意中加了 headers: { 'Authorization': 'Bearer xxx' }，就把一个 POST 变成非简单请求，而服务端没配 OPTIONS 路由或没返回对应头，结果请求卡在预检阶段，控制台报错 “CORS header ‘Access-Control-Allow-Origin’ missing”。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
后端必须配置的核心响应头
这些头只能由服务端设置，前端无法伪造或覆盖。典型组合如下：
-
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），后端必须在这里显式声明
替代方案：什么时候不用 CORS
当无法控制目标接口（如调用第三方公开 API），或出于安全考虑不想暴露真实后端地址时，可考虑其他路径：
-
代理转发：开发时用 Vite/webpack-dev-server 的 proxy，或上线后用 Nginx 反向代理。前端请求
/api/xxx，Nginx 把它转给https://third-party.com/xxx，因请求始终同源，浏览器不干预 -
JSONP（仅作了解）：利用
<script>标签无跨域限制的特性，但仅支持 GET，有 XSS 风险，错误难捕获，现代项目已基本淘汰
优先选 CORS 或代理。前者标准、灵活、安全；后者零前端改造、适用场景广，且能隐藏敏感参数或做统一鉴权。
