什么是跨域？
跨域（Cross-Origin Resource Sharing，CORS）是一种机制，它允许在 Web 页面上运行的脚本能够请求从不同源（域名、协议或端口）的资源。在浏览器安全策略中，有一条称为同源策略（Same-Origin Policy）的规则用以限制从一个源加载的文档或脚本如何与另一个源的资源进行交互。同源策略旨在防止恶意文档窃取数据、破坏用户的隐私等安全问题。
同源策略规定，如果两个 URL 的协议、域名和端口号都相同，则它们具有相同的源（Origin）。例如：
http://example.com/app1和http://example.com/app2是同源的。http://example.com和http://sub.example.com是跨域的。http://example.com和https://example.com是跨域的。http://example.com:80和http://example.com:8080是跨域的。
如果你的 Web 应用中包含从其他源获取资源的需求（例如，前端应用从不同域名的 API 服务器请求数据），同源策略将默认阻止这种跨源 HTTP 请求。为了解决这个问题，可以使用 CORS。
CORS 通过在服务器端返回特定的 HTTP 头来告诉浏览器允许本次请求。这些 CORS 响应头部信息让浏览器了解服务器允许的来源、HTTP 方法以及其他一些安全设置。
下面是一些常见的 CORS 响应头：
Access-Control-Allow-Origin: 指定了可以访问资源的 URI。可以是具体的 URI 或*（代表任意域名）。Access-Control-Allow-Methods: 指定了服务器支持的所有跨域请求的方法（如 GET, POST, PUT, DELETE 等）。Access-Control-Allow-Headers: 用在对预请求的响应中，表示实际请求可以包含的 HTTP 头列表。Access-Control-Allow-Credentials: 表示是否可以将请求的响应暴露给前端的 JavaScript 代码。当值为 true 时，表示可以。
当浏览器执行跨源 HTTP 请求时，根据请求的类型，它可能首先发起一个预请求（preflight request），这是一种使用 OPTIONS 方法的 HTTP 请求，用来检查真实请求是否安全。服务器必须响应预请求并指明哪些 HTTP 方法和头信息是允许的。
在 Spring 框架中，你可以使用 @CrossOrigin 注解在控制器或请求映射上声明 CORS 配置，或者使用全局配置来定义 CORS 策略。
跨域通常是 Web 开发中的一个常见问题，尤其是在前后端分离的架构模式中，了解如何正确地配置和使用 CORS 是非常重要的。
注解介绍
@CrossOrigin 注解是 Spring 框架提供的一种途径，用以在控制器级别或单独的处理器方法（handler method）上启用 CORS（Cross-Origin Resource Sharing）。这个注解可以用于支持跨源请求，允许你指定哪些域可以访问应用的响应。
你可以使用 @CrossOrigin 注解来设置如下 CORS 相关的配置选项：
origins：一个或多个允许跨域请求的域。默认为*，表示允许所有域的请求。methods：一个或多个允许的 HTTP 方法。默认为@RequestMapping中指定的方法，或者GET,HEAD,POST如果@RequestMapping没有指定。allowedHeaders：一个或多个允许的请求头。exposedHeaders：一个或多个在响应中可以暴露给客户端的响应头。maxAge：预请求缓存的最大时间（以秒为单位）。默认为1800秒（30 分钟）。allowCredentials：是否允许用户凭证。默认为true。
这里有一个使用 @CrossOrigin 注解的例子：
java
@RestController
@RequestMapping("/api")
public class MyApiController {
// 应用于单个控制器方法
@CrossOrigin(origins = "https://example.com")
@GetMapping("/users")
public List<User> getUsers() {
// ...
return userList;
}
// 应用于整个控制器类
@CrossOrigin(origins = "*", maxAge = 3600)
@GetMapping("/projects")
public List<Project> getProjects() {
// ...
return projectList;
}
}在上面的示例中，getUsers 方法中的 @CrossOrigin 注解指定了只有来自 https://example.com 的跨域请求才能访问该接口。而 getProjects 方法的 @CrossOrigin 注解由于没有指定 origins，默认允许来自所有域的请求，并且指定了预请求的最大缓存时间为 3600 秒（1 小时）。
如果你想为整个控制器类的所有方法启用相同的 CORS 配置，可以将 @CrossOrigin 注解放在类级别，如下所示：
java
@CrossOrigin(origins = "https://example.com", maxAge = 3600)
@RestController
@RequestMapping("/api")
public class MyApiController {
// 控制器方法
}此时，类级别的 @CrossOrigin 配置将应用于控制器中的所有处理器方法。
此外，你也可以通过全局配置来设置 CORS，这通常在 Spring 应用的配置类（如使用 @Configuration 注解的类）中完成。全局 CORS 配置会影响整个应用中所有控制器的所有跨域请求。
java
@Configuration
public class WebConfig implements WebMvcConfigurer {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOrigins("https://example.com")
.allowedMethods("GET", "POST", "PUT", "DELETE")
.allowedHeaders("*")
.allowCredentials(true)
.maxAge(3600);
}
}在上面的全局 CORS 配置中，所有控制器中的所有路由都将允许来自 https://example.com 的跨域请求，并且允许特定的 HTTP 方法。这种全局配置适合于当你希望整个应用有一致的跨域策略时使用。
请注意，类级别或方法级别的 @CrossOrigin 注解的设置会覆盖全局 CORS 配置。
前后端分离的单页面应用，后面接口如何配置跨域？
对于前后端分离的单页面应用（SPA），后端接口配置允许跨域的 origins 应该是前端应用所部署的 URL。这种配置使得浏览器可以允许从前端应用的源向后端发起跨域请求。
例如，假设你的前端应用部署在 https://my-spa-frontend.com，而后端 API 部署在 https://my-backend-api.com。为了让前端应用能够正常地从后端 API 请求数据，后端应该在 CORS 配置中的 origins 中指定 https://my-spa-frontend.com：
java
@CrossOrigin(origins = "https://my-spa-frontend.com")
@RestController
public class MyApiController {
// API 方法
}这样配置后，当浏览器从 https://my-spa-frontend.com 发出对 https://my-backend-api.com 的 AJAX 请求时，浏览器将识别到后端 API 允许来自 https://my-spa-frontend.com 的跨域请求，并允许这些请求成功访问资源。
如果你的前端应用有多个部署环境（如开发、测试和生产环境），你可能需要根据环境来设置不同的 origins：
java
@CrossOrigin(origins = {"https://dev-frontend.com", "https://test-frontend.com", "https://my-spa-frontend.com"})
@RestController
public class MyApiController {
// API 方法
}或者，在实际部署时，你可以使用环境变量或配置文件来动态设置 CORS 的 origins，使其适应不同的部署环境。
还要注意，对于开发环境，有时开发人员会使用特殊的值 *，这表示允许所有域的请求，这在开发阶段是方便的，但出于安全考虑，通常不推荐在生产环境中使用此设置：
java
// 只在开发环境中使用
@CrossOrigin(origins = "*")
@RestController
public class MyApiController {
// API 方法
}总之，origins 应该包含允许访问后端 API 的前端应用的 URL，从而为前后端分离的单页面应用启用跨域请求。在生产环境中，应该使用具体的域名而不是通配符 *，以确保应用的安全性。
其他方式
跨域（CORS）也可以在网关层实现，比如使用 Nginx。通常，这种方法可以更加集中和统一地管理跨域策略，并且可以减轻后端应用服务器的一些配置负担。
在 Nginx 中实现 CORS 的基本思路是在响应头中添加相应的 CORS 头信息。这些信息告诉浏览器，Nginx 服务允许来自特定原（origin）的跨域请求。
以下是在 Nginx 中配置 CORS 的基本步骤：
-
打开 Nginx 配置文件，通常位于
/etc/nginx/nginx.conf或/etc/nginx/conf.d/目录下的某个文件中。 -
在
server块或具体的location块中，添加配置来定义允许的源（Access-Control-Allow-Origin）、HTTP 方法（Access-Control-Allow-Methods）等 CORS 头信息。 -
重启 Nginx 以应用更改。
下面是一个 Nginx 配置 CORS 的例子：
bash
server {
listen 80;
server_name my-backend-api.com;
location / {
# 你的代理或其他配置
# CORS 配置
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' 'https://my-spa-frontend.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Content-Length' '0';
add_header 'Content-Type' 'text/plain charset=UTF-8';
add_header 'Access-Control-Max-Age' '1728000';
return 204;
}
if ($request_method = 'POST') {
add_header 'Access-Control-Allow-Origin' 'https://my-spa-frontend.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
add_header 'Access-Control-Allow-Credentials' 'true';
}
if ($request_method = 'GET') {
add_header 'Access-Control-Allow-Origin' 'https://my-spa-frontend.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
add_header 'Access-Control-Allow-Credentials' 'true';
}
}
}在上述配置中，我们为 OPTIONS 请求添加了 CORS 预检（preflight）请求所需的响应头，允许来自 https://my-spa-frontend.com 的跨域请求，并指定了允许的方法和头信息。对于实际的 POST 和 GET 请求，也添加了类似的头信息。
请注意，配置应该根据你的具体需求进行调整。例如，如果你想要允许多个来源，可能需要一些额外的逻辑来检查请求头中的 Origin 并动态地设置 Access-Control-Allow-Origin。
使用 Nginx 实现 CORS 可以使得跨域策略的管理更加集中，在使用微服务架构或多个后端服务时尤其方便。不过，值得注意的是，确保 Nginx 的 CORS 设置与你的应用安全策略保持一致是非常重要的。