在现代 Web 开发中，前后端分离已成为主流架构模式。作为 Java 后端开发者，在与前端协作时，几乎不可避免地会遇到一个经典难题——跨域问题（CORS）。当前端页面通过浏览器发起 Ajax 请求，试图访问与当前页面不同源（协议、域名或端口任一不同）的后端接口时，浏览器出于安全策略会自动拦截响应，导致请求“看似成功却拿不到数据”。这种现象常让初涉全栈开发的 Java 工程师感到困惑：“明明 Postman 能调通，为什么前端就是不行？”
本文从 Java 开发者的视角出发，不谈前端框架细节，也不贴代码，而是聚焦于三种最常用、最实用的跨域解决方案及其适用场景与注意事项，帮助你在项目早期规避这一高频“坑点”。
一、方案一：后端配置 CORS 响应头（推荐首选）
这是最标准、最符合 Web 规范的解决方式。其核心思想是：由后端主动告诉浏览器，“我允许来自哪些源的请求访问我的资源”。
具体做法是在 Java Web 应用（如 Spring Boot）中，通过配置全局或局部的跨域策略，让服务器在响应中自动添加如下关键 HTTP 头部：
Access-Control-Allow-Origin：指定允许访问的前端域名（如https://web.example.com），也可设为*（但存在安全限制）；Access-Control-Allow-Methods：允许的 HTTP 方法（GET、POST 等）；Access-Control-Allow-Headers：允许前端携带的自定义请求头（如Authorization、Content-Type）；- 若涉及 Cookie 或认证信息，还需设置
Access-Control-Allow-Credentials: true，此时Allow-Origin不能为*。
优势：
- 符合 W3C 标准，兼容性好；
- 精细控制权限，安全性高；
- 无需改动部署架构。
注意事项：
- 预检请求（Preflight Request）：对于非简单请求（如带自定义 Header 的 POST），浏览器会先发 OPTIONS 请求探路，后端必须正确处理并返回 200，否则主请求不会发出；
- 生产环境切勿随意使用
Allow-Origin: *，尤其当接口涉及用户身份认证时。
二、方案二：通过 Nginx 反向代理统一域名（部署层解耦）
此方案的核心思路是：让前端和后端在浏览器看来“同源”。具体做法是在前端部署服务器（如 Nginx）上配置反向代理规则，将对 API 的请求转发到真实的后端服务地址。
例如，前端页面部署在https://app.example.com，原本需调用http://api.example.com:8080/user。通过 Nginx 配置，可将所有/api/**路径的请求代理到后端 Java 服务。这样，前端只需请求https://app.example.com/api/user，浏览器认为是同源请求，自然不会触发跨域限制。
优势：
- 对前端完全透明，无需任何跨域处理逻辑；
- 后端无需修改代码，保持纯净；
- 便于统一管理 API 入口、限流、SSL 终止等。
注意事项：
- 需要运维或 DevOps 支持，依赖反向代理服务器的配置能力；
- 调试阶段需注意本地开发环境（如 localhost:3000）与代理配置的协调，通常需在本地也启动一个简易代理（如 Vite 或 Webpack DevServer 的 proxy 功能）；
- 不适用于纯静态托管（如 GitHub Pages）且无法控制服务器的场景。
三、方案三：JSONP（仅限 GET 请求，已基本淘汰）
JSONP（JSON with Padding）是一种利用<script>标签不受跨域限制的“取巧”方案。前端动态创建 script 标签，请求一个特殊格式的 URL，后端返回一段可执行的 JavaScript 函数调用，将数据作为参数传入。
局限性极大：
- 仅支持 GET 请求，无法用于 POST、PUT 等操作；
- 无错误处理机制，调试困难；
- 存在 XSS 安全风险；
- 现代前端框架（React、Vue 等）几乎不再使用。
结论：除非维护非常老旧的系统，否则不建议采用 JSONP。它属于历史遗留方案，已被 CORS 全面取代。
如何选择？
- 新项目、可控后端→ 优先使用方案一（CORS 配置），标准、灵活、安全；
- 多前端、多后端、微服务架构→ 推荐方案二（Nginx 反向代理），解耦清晰，运维友好；
- 避免使用 JSONP，除非别无选择。
结语
跨域问题本质是浏览器的安全机制，而非后端 Bug。作为 Java 程序员，理解其原理并掌握上述三种解决方案，不仅能高效协同前端团队，更能体现你对 Web 架构的整体把控能力。记住：最好的跨域处理，是在设计阶段就规划好前后端的部署与通信策略，而不是等到联调时才“打补丁”。避开这个坑，你的全栈之路会顺畅许多。
