跨域机制的核心是浏览器同源策略，它仅在浏览器中生效，要求协议、域名、端口三者完全一致；不满足即跨域，限制的是脚本对响应体、跨源dom及本地存储的读取权，而非网络请求本身。
跨域机制的核心不是“怎么绕过”，而是“浏览器为什么拦你”。理解这一点，方案选择就自然清晰了。
先搞懂同源策略到底拦什么
同源策略只在浏览器里生效，它要求协议、域名、端口三者完全一致。不满足任一条件，就算跨域。它限制的不是网络通信本身，而是脚本对响应内容的读取权——比如你用 fetch 发请求，请求其实发出去了，服务器也返回了数据，但浏览器检查响应头后发现没授权，就把响应体悄悄丢掉，前端拿到的只是“被拦截”的错误。
它重点拦三类行为：
- XMLHttpRequest 或 fetch 的响应体读取（AJAX）
- iframe 内 DOM 的访问（如 contentWindow.document）
- Cookie、LocalStorage 等本地存储的跨源读写
CORS 是默认首选，但得配对用对
CORS 不是前端“加个参数”就能通的，它是前后端协作机制：前端按正常方式发请求，浏览器自动加 Origin 头；服务端收到后，决定是否允许，并在响应中带上 Access-Control-Allow-Origin 等头部。
关键细节要盯住：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 简单请求（GET/POST + 常见 Content-Type）直接发，服务端只需返回正确响应头
- 带自定义 header、用 PUT/DELETE、传 JSON 数据体 → 触发预检（OPTIONS 请求），服务端必须能正确响应 OPTIONS，否则真实请求根本不会发
- 要带 Cookie 或认证信息，必须同时设置：credentials: 'include'（前端）+ Access-Control-Allow-Credentials: true（服务端）+ Access-Control-Allow-Origin 不能为 *（必须写具体域名）
JSONP 只适合极少数兜底场景
它本质是“骗浏览器”：利用 <script> 标签不受同源限制的特性，让服务端把数据包装成函数调用返回。前端提前定义好回调函数，脚本一加载就执行。</script>
但它有硬伤：
- 只支持 GET，没法 POST、上传文件、带 header
- 没有错误捕获机制——URL 错了、服务端崩了、网络断了，都只能靠超时模拟，无法区分原因
- 执行第三方 JS，XSS 风险高，现代项目基本弃用
现在只剩两种合理使用场景：老系统无法改后端、纯静态页面连代理都搭不了。
代理是开发阶段最省心的解法
它不解决“跨域”，而是让跨域消失：前端请求发给同源的本地服务（如 localhost:3000/api），这个服务再把请求转发到真实后端（如 http://api.example.com）。对浏览器来说，全程都是同源通信。
- 开发环境常用 webpack/vite devServer.proxy 或 vite.config.ts 中的 server.proxy
- 生产环境可用 Nginx 反向代理，配置简单且能隐藏真实接口地址
- 注意：代理只在开发或服务端可控时有效，不能用于直接部署的静态页
真正“彻底理解”，就是明白每种方案在哪个环节起作用、谁负责哪部分、失败时卡在哪一步。选方案不是看名字新不新，而是看你的控制权在哪——能配服务端？上 CORS。不能动后端？看能不能搭代理。连服务器都没有？再考虑 JSONP 或 postMessage 这类替代路径。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
