服务器跨域方式有哪些？哪种最适合高并发场景？

服务器端跨域解决方案

在现代Web开发中，跨域资源共享（CORS）是一个无法回避的话题，由于浏览器的同源策略（Same-Origin Policy），当前域下的脚本无法直接访问其他域的资源，这既保障了用户数据安全，也带来了前后端分离架构下的通信难题，本文将系统介绍服务器端处理跨域的主要方式，涵盖原理、实现场景及最佳实践，帮助开发者构建安全且高效的前后端交互体系。

理解跨域与CORS机制

跨域是指浏览器从一个域名的网页去请求另一个域名的资源时，若协议、域名或端口任一不同，则视为跨域。https://example.com 的前端页面请求 https://api.test.com/data 就属于跨域请求，浏览器会遵循同源策略拦截请求，除非服务器明确允许该请求。

CORS（Cross-Origin Resource Sharing）是W3C标准化的跨域解决方案，通过HTTP头部信息定义服务器对跨域请求的授权规则，其核心在于服务器响应中的 Access-Control-Allow-Origin 等头部字段，若服务器返回的头部中包含允许当前域的声明，浏览器则解除拦截，允许资源交互。

基础CORS配置：简单请求的处理

根据CORS规范，HTTP请求分为“简单请求”和“非简单请求”，简单请求需满足以下条件：

• 请求方法为 GET、POST 或 HEAD；
• HTTP头部仅限于 Accept、Accept-Language、Content-Language、Content-Type（且值为 application/x-www-form-urlencoded、multipart/form-data 或 text/plain）；
• 请求中没有自定义头部字段。

对于简单请求，服务器只需在响应中添加以下关键头部即可：

• Access-Control-Allow-Origin：指定允许的跨域源，可设为具体域名（如 https://example.com）或 （允许所有源，需注意安全性）；
• Access-Control-Allow-Methods：允许的请求方法，如 GET, POST, PUT；
• Access-Control-Allow-Headers：允许的请求头字段，如 Content-Type, Authorization。

示例（Node.js + Express）：

const express = require('express');
const app = express();
app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', 'https://example.com');
  res.header('Access-Control-Allow-Methods', 'GET, POST');
  res.header('Access-Control-Allow-Headers', 'Content-Type');
  next();
});
app.get('/data', (req, res) => {
  res.json({ message: 'CORS simple request success' });
});
app.listen(3000);

预检请求（Preflight Request）处理

非简单请求（如 PUT、DELETE 请求，或包含自定义头部的请求）会先发送一个 OPTIONS 请求到服务器，即“预检请求”，用于询问服务器是否允许实际的跨域请求，只有预检通过后，才会发送真正的请求。

预检请求的核心是 Access-Control-Request-Method 和 Access-Control-Request-Headers 头部，分别告知服务器本次请求的方法和自定义头部，服务器需响应以下头部：

• Access-Control-Allow-Methods：允许的实际请求方法；
• Access-Control-Allow-Headers：允许的自定义头部；
• Access-Control-Max-Age：预检结果的有效期（单位：秒），避免重复发送预检请求。

示例（处理预检请求）：

app.options('/data', (req, res) => {
  res.header('Access-Control-Allow-Origin', 'https://example.com');
  res.header('Access-Control-Allow-Methods', 'PUT, DELETE');
  res.header('Access-Control-Allow-Headers', 'X-Custom-Header');
  res.header('Access-Control-Max-Age', 86400); // 预检结果缓存24小时
  res.sendStatus(204);
});

携带身份凭证的跨域请求

当前端请求需要携带Cookie、HTTP认证等身份凭证时，需满足以下条件：

• 服务器响应的 Access-Control-Allow-Origin 不能为 ，必须明确指定允许的域名；
• 设置 Access-Control-Allow-Credentials: true；
• 前端请求需配置 withCredentials: true（如Axios中）。

示例（携带Cookie的跨域请求）：

// 前端Axios请求
axios.get('https://api.test.com/data', {
  withCredentials: true,
  headers: { 'Authorization': 'Bearer token123' }
});
// 服务器响应
res.header('Access-Control-Allow-Origin', 'https://example.com');
res.header('Access-Control-Allow-Credentials', 'true');
res.header('Access-Control-Allow-Headers', 'Authorization');

高级场景：自定义CORS策略

在实际业务中，可能需要更灵活的CORS控制，

• 动态域名白名单：根据请求来源动态判断是否允许跨域；
• 分环境配置：开发环境允许所有源，生产环境限制特定域名；
• 复杂头部处理：支持自定义业务头部（如 X-Token）。

示例（动态域名白名单）：

const allowedOrigins = ['https://example.com', 'https://app.example.com'];
app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (allowedOrigins.includes(origin)) {
    res.header('Access-Control-Allow-Origin', origin);
  }
  res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
  res.header('Access-Control-Allow-Headers', 'Content-Type, X-Token');
  next();
});

替代方案与注意事项

除CORS外，服务器端还可通过以下方式实现跨域，但需结合场景权衡：

1. JSONP（仅支持GET请求）：
   通过动态创建 <script> 标签，利用 <script> 标签的跨域能力返回回调函数数据，但JSONP存在安全风险（如XSS攻击），且仅支持GET请求，已逐渐被CORS替代。

2. 代理服务器：
   若前端与服务器同源，可通过Nginx、Cloudflare等代理服务器转发请求，将跨域转化为同源请求。

   location /api/ {
     proxy_pass https://api.test.com/;
     proxy_set_header Host api.test.com;
   }

注意事项：

• 安全性：避免在生产环境中滥用 Access-Control-Allow-Origin: *，尤其是涉及敏感数据时；
• 性能优化：合理设置 Access-Control-Max-Age 减少预检请求次数；
• 错误处理：对跨域请求的错误（如401、403）返回清晰的错误信息，便于前端调试。

服务器端跨域处理的核心是明确告知浏览器哪些跨域请求是被允许的，CORS作为标准解决方案，支持GET、POST、PUT等所有HTTP方法，并能处理携带凭证的复杂场景，开发者需根据业务需求选择合适的配置方式，兼顾安全性与灵活性，在实际开发中，建议结合中间件（如CORS库）简化配置，同时通过代理服务器或环境变量管理不同场景下的跨域策略,确保前后端交互的高效与稳定。