每个人都可以，
拥有SSL证书

跨域这回事，前端做得越久碰到的次数越多。

浏览器同源策略卡在那里，协议、域名、端口有任何一个不一样，请求就发不出去。下面把 CORS、JSONP 和 Nginx 反向代理这三条路分别理一遍，顺带说一些线上容易踩的坑。

先说 CORS，现在处理跨域的大头基本都是它。

原理不复杂，就是服务端在响应头里加上 Access-Control-Allow-Origin，告诉浏览器哪些源可以访问。不过这里面细节不少，比如简单请求和复杂请求的区别。GET、HEAD 以及部分 POST（Content-Type 是表单那几种）会被当作简单请求直接发出去；一旦用了 PUT、DELETE 或者自定义头，浏览器就会先发一个 OPTIONS 预检请求，服务端得正确响应这个 OPTIONS，否则真正的请求根本不会发出去。

Node.js 里用 cors 中间件配置一下就能跑起来，一个典型的配置长这样：

const express = require('express'); const cors = require('cors'); const app = express();

const corsOptions = { origin: 'http://your-frontend-domain.com', methods: 'GET,HEAD,PUT,PATCH,POST,DELETE', allowedHeaders: ['Content-Type', 'Authorization'], credentials: true, };

app.use(cors(corsOptions));

如果需要带 Cookie，前端 xhr 或者 fetch 得设置 withCredentials 为 true，同时服务端 Access-Control-Allow-Credentials 也要设为 true，并且 Origin 不能配成 *，必须指定具体域名，不然浏览器还是会拦截。

再来说 JSONP。

这东西在 IE 时代用得很多，现在基本只会在老项目或者一些特殊对接场景里见到了。它利用的是 script 标签不受同源策略限制的特点，动态往页面里插一个 script，src 指向接口地址并带上回调函数名，服务端返回一段 JS 代码，直接调用那个回调并把数据塞进去。

前端可以这么干：

function handleResponse(data) { console.log('Received:', data); }

const script = document.createElement('script'); script.src = 'https://api.other-domain.com/data?callback=handleResponse'; document.body.appendChild(script);

服务端返回的内容大致就是 handleResponse({ "status": "success", "data": [...] })。

JSONP 的硬伤也很明显：只支持 GET，没办法处理错误状态码，而且安全问题比较棘手，容易 XSS。如果没有特殊兼容需求，新项目基本不会再考虑它了。

然后是 Nginx 反向代理。很多时候跨域问题不是因为前后端分离得有多彻底，而是开发环境里前端直接调了不同域名的后端接口。

这种情况下让 Nginx 在前面挡一层，把同域下的 /api 路径代理到真实服务上，浏览器只跟一个源打交道，跨域自然就不存在了。

一段简单的 Nginx 配置：

server { listen 80; server_name my-domain.com; location /api/ { proxy_pass https://api.other-domain.com/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; add_header 'Access-Control-Allow-Origin' 'http://your-frontend-domain.com'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'Content-Type'; } }

这里的 add_header 顺便加上了 CORS 头，这样即使后端没处理，Nginx 层也能兜底。不过要留个心，如果后端也设置了 CORS 头，可能会重复，有些情况会导致浏览器报错。实际用的时候可以先确认后端是否会返回这些头，再决定 Nginx 侧要不要加。

三种方案的选型其实没那么复杂。CORS 是标准做法，前后端都方便，绝大多数 API 接口跨域用它就行，但要严格限制 Origin，别图省事写成 *。JSONP 基本只用来兼容个别老旧浏览器，或者偶尔处理那些完全没法配置服务端的第三方接口，前提是能接受它的安全隐患。

Nginx 代理适合前端不想或者不能改动代码的部署场景，多一次代理会稍微增加一点服务器开销，维护代理规则也得跟上。

线上配置的时候，还有几个容易忽略的点。

安全方面，CORS 的 Access-Control-Allow-Origin 千万不要配 *，老老实实写成可信域名；如果用 JSONP，最好加上 CSRF Token 校验，哪怕只是简单验证一下 Referer 也行。

性能上，预检请求一旦多了，页面加载会明显变慢。可以设置 Access-Control-Max-Age 来缓存预检结果，减少重复的 OPTIONS 请求。

另外，通过 Nginx 开启 gzip 或 brotli 压缩代理返回的数据，也能提升传输速度。

异常监控同样不能省。

前端可以统一捕获跨域错误上报，看到类似 “blocked by CORS policy” 的报错马上能定位到问题。Nginx 的访问日志和错误日志是查代理问题的第一手资料，建议保持开启。服务端那边，如果 OPTIONS 请求量异常增高，多半是哪里配置不对或者有人在做试探，及时排查就好。

这些方案本身都不难，但要在生产环境里用得稳，靠的还是对同源策略的理解和对细节的把控。