在之前的分享中，我们介绍了跨域问题的基础实现方式以及解决方案，这里我们继续基于上篇的内容给出实战以及技术选型案例

实际项目案例：Spring Boot3 + Vue3 跨域解决方案落地

理论结合实践才能更好地掌握跨域配置，以下以 “Spring Boot3 后端 + Vue3 前端” 的前后端分离项目为例，展示不同场景下的跨域解决方案落地，覆盖开发环境、生产环境及与 Spring Security 整合的场景。

（一）开发环境：简化配置提升效率

开发环境中，前端通常运行在 http://localhost:8080，后端运行在 http://localhost:9090，需快速实现跨域调试，无需过度强调安全性：

后端全局 CORS 配置：使用 WebMvcConfigurer 实现全局配置，允许前端本地地址跨域，同时允许所有常用方法和请求头，减少调试阻碍：

@Configuration
public class DevCorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**") // 仅对/api前缀的接口配置跨域（避免非业务接口暴露）
                .allowedOrigins("http://localhost:8080") // 开发环境仅允许前端本地地址
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600); // 预检请求缓存1小时，减少重复请求
    }
}

前端无需额外配置：Vue3 项目中使用 Axios 发送请求时，直接指定后端地址即可，无需添加跨域相关参数：

import axios from 'axios';
const request = axios.create({
    baseURL: 'http://localhost:9090/api', // 后端接口基础路径
    timeout: 5000
});
// 示例：发送GET请求
request.get('/user/info').then(res => {
    console.log(res.data);
}).catch(err => {
    console.error('请求失败：', err);
});

（二）生产环境：安全优先的精细化配置

生产环境中，前端部署在 https://www.frontend.com，后端部署在 https://api.backend.com，需严格限制跨域来源，避免恶意网站利用跨域漏洞：

后端配置指定允许的域名：将 allowedOrigins 设置为前端生产环境域名，同时限制请求头和方法，仅开放业务必需的配置：

@Configuration
public class ProdCorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
                .allowedOrigins("https://www.frontend.com") // 仅允许生产环境前端域名
                .allowedMethods("GET", "POST", "PUT", "DELETE") // 禁用不必要的OPTIONS方法（生产环境中预检请求已缓存）
                .allowedHeaders("Content-Type", "Authorization") // 仅允许业务必需的请求头（如Content-Type、令牌头Authorization）
                .allowCredentials(true)
                .maxAge(86400); // 预检请求缓存24小时，降低服务器压力
    }
}

配合 Nginx 反向代理优化性能：生产环境中，可通过 Nginx 配置反向代理，将前端对 /api 的请求转发到后端，避免浏览器直接发送跨域请求 —— 这种方式本质上是 “同源请求代理”，能减少 CORS 预检请求，提升性能。Nginx 配置示例：

server {
    listen 443 ssl;
    server_name www.frontend.com; # 前端域名

    # SSL配置（省略）
    ssl_certificate /etc/nginx/ssl/frontend.crt;
    ssl_certificate_key /etc/nginx/ssl/frontend.key;

    # 反向代理后端API
    location /api/ {
        proxy_pass https://api.backend.com/api/; # 转发到后端地址
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # 前端静态资源配置（省略）
    location / {
        root /usr/share/nginx/html/frontend;
        index index.html;
        try_files $uri $uri/ /index.html; # 适配Vue路由History模式
    }
}

此时前端 Axios 的 baseURL 可设置为 /api（与前端同源），无需跨域配置，请求会通过 Nginx 转发到后端，既提升安全性，又减少跨域请求的性能损耗。

（三）整合 Spring Security 的跨域配置

若项目中使用 Spring Security 进行身份验证（如 JWT 令牌验证），需特别注意 CORS 配置与 Security 的兼容性 ——Spring Security 的拦截器优先级高于普通 CORS 过滤器，若未正确配置，会导致 CORS 响应头被 Security 拦截。

正确的配置步骤：

• 关闭 Security 的默认 CORS 配置：在 Spring Security 配置类中，通过 cors().disable() 关闭默认 CORS 处理，避免与自定义 CORS 配置冲突。
• 将 CORS 过滤器纳入 Security 过滤链：通过 addFilterBefore 方法，将自定义 CORS 过滤器添加到 Security 的 UsernamePasswordAuthenticationFilter 之前，确保 CORS 响应头在身份验证之前返回。

具体代码示例：

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    // 注入自定义CORS过滤器
    @Autowired
    private SimpleCorsFilter corsFilter;

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .cors().disable() // 关闭默认CORS配置
            .csrf().disable() // 前后端分离项目通常关闭CSRF（若使用JWT）
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/public/**").permitAll() // 公开接口无需认证
                .anyRequest().authenticated() // 其他接口需认证
            )
            .addFilterBefore(corsFilter, UsernamePasswordAuthenticationFilter.class); // 将CORS过滤器添加到Security过滤链

        return http.build();
    }
}

此外，需确保 Security 允许 OPTIONS 预检请求 —— 由于 OPTIONS 请求不携带令牌，若 Security 拦截 OPTIONS 请求，会导致预检失败。可在 authorizeHttpRequests 中添加 requestMatchers(HttpMethod.OPTIONS, "/**").permitAll()，允许所有 OPTIONS 请求匿名访问：

.authorizeHttpRequests(auth -> auth
    .requestMatchers(HttpMethod.OPTIONS, "/**").permitAll() // 允许OPTIONS请求
    .requestMatchers("/api/public/**").permitAll()
    .anyRequest().authenticated()
)

Spring Boot3 中跨域相关的新特性与注意事项

Spring Boot3 基于 Spring Framework 6，在 CORS 处理上有部分细节优化，同时也存在一些与旧版本不兼容的地方，开发者在升级或新建项目时需特别注意。

（一）Spring Boot3 的 CORS 优化点

支持通配符域名配置：在 Spring Boot3 中，allowedOrigins 支持更灵活的通配符配置，例如 allowedOrigins("https://*.example.com")，可允许同一主域名下的所有子域名跨域（如 https://a.example.com、https://b.example.com），无需逐一指定子域名，减少配置冗余。

预检请求缓存默认值调整：Spring Boot3 中，maxAge（预检请求缓存时间）的默认值从原来的 1800 秒（30 分钟）调整为 86400 秒（24 小时），减少频繁的预检请求，提升跨域请求效率。若需修改，可在 addCorsMappings 中手动指定 maxAge 值。

与 Jakarta Servlet API 的兼容性：Spring Boot3 全面迁移到 Jakarta Servlet API（从 javax.servlet 改为 jakarta.servlet），因此自定义 CORS 过滤器时，需导入 jakarta.servlet.Filter 接口，而非旧的 javax.servlet.Filter。若使用旧的导入路径，会导致过滤器无法加载，出现 ClassNotFoundException 错误。

示例：Spring Boot3 中正确的过滤器导入：

// 正确：使用Jakarta Servlet API
import jakarta.servlet.Filter;
import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletRequest;
import jakarta.servlet.ServletResponse;
import jakarta.servlet.http.HttpServletResponse;

// 错误：旧的javax.servlet API（Spring Boot3中已不支持）
// import javax.servlet.Filter;
// import javax.servlet.FilterChain;

（二）常见配置误区与避坑指南

allowCredentials=true 与 allowedOrigins="*" 冲突：当 allowCredentials 设置为 true（允许前端携带 Cookie 或令牌）时，allowedOrigins 不能使用 *（通配符），否则浏览器会拒绝跨域响应 —— 因为 * 表示允许所有来源，而携带凭证的跨域请求需要明确指定来源，避免安全风险。若需允许多个来源且携带凭证，需通过 allowedOrigins 逐一指定，或通过动态判断请求的 Origin 是否在白名单中，再设置
Access-Control-Allow-Origin 响应头。

动态配置示例：

public class DynamicCorsFilter implements Filter {
    // 跨域白名单
    private static final List<String> ALLOWED_ORIGINS = Arrays.asList(
        "https://www.frontend1.com",
        "https://www.frontend2.com"
    );

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;

        // 获取请求来源
        String origin = request.getHeader("Origin");
        // 若来源在白名单中，设置允许跨域
        if (ALLOWED_ORIGINS.contains(origin)) {
            response.setHeader("Access-Control-Allow-Origin", origin);
            response.setHeader("Access-Control-Allow-Credentials", "true");
            response.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
            response.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization");
        }

        chain.doFilter(req, res);
    }
}

重复配置导致冲突：若项目中同时使用 @CrossOrigin 注解和全局 CORS 配置，会导致配置冲突 ——@CrossOrigin 注解的优先级高于全局配置，即某个 Controller 方法若添加了 @CrossOrigin，会覆盖全局配置。若需统一管理跨域规则，建议删除所有 @CrossOrigin 注解，仅保留全局配置，避免规则混乱。

忽略静态资源的跨域配置：若前端需要加载后端的静态资源（如图片、文件），需确保 CORS 配置覆盖静态资源路径。例如，若静态资源放在 /static 目录下，需在全局配置中设置 addMapping("/**")（覆盖所有路径），或明确指定 addMapping("/static/**")，避免静态资源请求被跨域拦截。

跨域解决方案的选择策略

在 Spring Boot3 项目中，不存在 “绝对最优” 的跨域解决方案，需根据项目场景（开发 / 生产、简单 / 复杂架构）、安全性要求和团队技术栈，选择最适合的方案。以下是不同场景下的选择建议：

跨域问题的核心是 “平衡安全性与灵活性”—— 既要在满足业务灵活性的同时，守住安全底线。无论是选择哪种解决方案，都需牢记 “最小权限” 原则 —— 仅开放必需的跨域来源、方法和请求头，避免因过度开放导致安全漏洞。

跨域问题的核心原则深化与扩展场景

（一）“同源策略” 的深层逻辑与边界

很多开发者对同源策略的理解停留在 “协议、域名、端口一致” 的表层，却忽略了其背后的安全设计逻辑 —— 同源策略本质是浏览器对 “资源访问权限” 的隔离机制，防止恶意网站通过 “跨域请求” 窃取用户在其他网站的敏感数据（如 Cookie、LocalStorage 中的登录态）。

需要明确的是，同源策略并非 “一刀切” 的拦截，而是存在明确的边界：

允许跨域加载资源，但限制跨域读取资源：浏览器允许从不同源加载图片、脚本、样式等静态资源（如 <img src="
http://other-domain.com/img.png">），但禁止通过 JavaScript 读取这些资源的内容（如获取图片的像素数据）。

简单请求与非简单请求的差异化处理：浏览器将跨域请求分为两类，简单请求（如 GET、POST 方法，且请求头仅包含 Accept、Content-Type 等少数安全头）可直接发送，无需预检；非简单请求（如 PUT/DELETE 方法、包含自定义请求头）则需先发送 OPTIONS 预检请求，确认服务器允许后再发送实际请求。这种差异化处理既保障了安全，又减少了简单场景下的性能损耗。

理解这些边界，能帮助开发者在遇到 “特殊跨域场景” 时快速判断问题本质。例如，当使用 <script> 标签加载跨域脚本时，若脚本中包含操作父页面 DOM 的逻辑，会被浏览器拦截，这正是同源策略对 “跨域脚本操作权限” 的限制。

（二）特殊场景下的跨域解决方案

除了前文提到的常规场景，实际开发中还会遇到一些特殊场景，需要针对性的跨域配置：

1.多前端应用共享后端接口

若一个后端服务需要支持多个前端应用（如 PC 端、移动端、小程序端），且这些前端应用部署在不同域名下，直接在 allowedOrigins 中逐一指定域名会导致配置冗余，且新增前端应用时需修改后端配置。

此时可通过 “动态白名单 + 配置中心” 的方式优化：

• 将允许的跨域域名存入配置中心（如 Nacos、Apollo），后端启动时从配置中心读取白名单，避免硬编码。
• 自定义 CORS 过滤器，每次请求时从配置中心获取最新白名单，判断请求的 Origin 是否在白名单中，动态设置 Access-Control-Allow-Origin 响应头。

示例代码（结合 Nacos 配置中心）：

@Component
public class DynamicNacosCorsFilter implements Filter {

    @Value("${cors.allowed-origins}")
    private List<String> allowedOrigins; // 从Nacos配置中心读取白名单，格式：https://pc.frontend.com,https://mobile.frontend.com

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;

        String origin = request.getHeader("Origin");
        // 若请求来源在白名单中，动态设置允许跨域
        if (origin != null && allowedOrigins.contains(origin)) {
            response.setHeader("Access-Control-Allow-Origin", origin);
            response.setHeader("Access-Control-Allow-Credentials", "true");
            response.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS");
            response.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization, X-Token");
            response.setHeader("Access-Control-Max-Age", "86400");
        }

        chain.doFilter(req, res);
    }

    // 监听Nacos配置变更，实时更新白名单
    @NacosConfigListener(dataId = "cors-config", groupId = "DEFAULT_GROUP")
    public void onConfigChange(String config) {
        JSONObject configJson = JSONObject.parseObject(config);
        String originsStr = configJson.getString("allowed-origins");
        this.allowedOrigins = Arrays.asList(originsStr.split(","));
    }
}

这种方式的优势在于：新增前端应用时，只需在配置中心添加域名，无需重启后端服务，实现 “无感知更新”。

2. 跨域请求携带自定义令牌（如 JWT）

在前后端分离项目中，常使用 JWT 令牌进行身份验证，令牌通常放在请求头（如 X-Token）中。此时需注意：

• 自定义请求头（如 X-Token）属于 “非简单请求头”，会触发 OPTIONS 预检请求，需在 CORS 配置中明确允许该请求头（allowedHeaders("X-Token")）。
• 若 allowCredentials 设置为 true，需确保前端发送请求时携带 Credentials（Axios 中需设置 withCredentials: true），否则后端无法获取 Cookie 或令牌对应的用户信息。

前端 Axios 配置示例：

const request = axios.create({
    baseURL: 'https://api.backend.com/api',
    timeout: 5000,
    withCredentials: true // 允许携带Credentials（Cookie、令牌等）
});

// 请求拦截器：添加自定义令牌头
request.interceptors.request.use(config => {
    const token = localStorage.getItem('x-token');
    if (token) {
        config.headers['X-Token'] = token;
    }
    return config;
}, error => {
    return Promise.reject(error);
});

后端 CORS 配置需添加 allowedHeaders("X-Token")，确保预检请求通过：

@Override
public void addCorsMappings(CorsRegistry registry) {
    registry.addMapping("/api/**")
            .allowedOrigins("https://www.frontend.com")
            .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
            .allowedHeaders("Content-Type", "Authorization", "X-Token") // 允许自定义令牌头
            .allowCredentials(true)
            .maxAge(86400);
}

3. 跨域请求中处理文件上传

当前端通过跨域请求上传文件（如图片、Excel）时，需注意两点：

请求头 Content-Type 的设置：文件上传请求的 Content-Type 通常为 multipart/form-data，属于 “非简单请求头”，需在 CORS 配置中允许该类型（allowedHeaders("Content-Type")）。

预检请求的处理：部分浏览器在文件上传前会发送 OPTIONS 预检请求，需确保服务器正确响应预检请求，避免因预检失败导致文件上传中断。

后端无需额外配置文件上传的跨域逻辑，只需确保 CORS 配置包含 multipart/form-data 对应的请求头即可。前端使用 Axios 上传文件的示例：

// 前端文件上传示例
const uploadFile = (file) => {
    const formData = new FormData();
    formData.append('file', file); // 添加文件到FormData

    return request({
        url: '/file/upload',
        method: 'POST',
        data: formData,
        // 无需手动设置Content-Type，Axios会自动设置为multipart/form-data
        headers: {
            'X-Token': localStorage.getItem('x-token')
        }
    });
};

未来技术趋势对跨域解决方案的影响

随着 Web 技术的发展，跨域解决方案也在不断演进，了解未来趋势能帮助开发者提前做好技术储备：

（一）HTTP/3 对跨域请求的性能优化

HTTP/3 基于 QUIC 协议，相比 HTTP/2 有更低的延迟和更高的吞吐量，对跨域请求的优化主要体现在：

减少预检请求的延迟：HTTP/3 的 “0-RTT” 连接建立机制，能大幅减少 OPTIONS 预检请求的网络延迟，尤其在跨域请求频繁的场景下，能显著提升用户体验。

多路复用的增强：HTTP/3 的多路复用机制避免了 HTTP/2 的 “队头阻塞” 问题，即使多个跨域请求同时发送，也不会相互影响，提升了并发处理能力。

对于 Spring Boot3 开发者而言，无需修改跨域配置即可享受 HTTP/3 的优化 —— 只需在服务器（如 Tomcat 10.1+、Jetty 11+）中启用 HTTP/3 协议，后端的 CORS 逻辑仍保持不变。

（二）WebAssembly 对跨域场景的拓展

WebAssembly（Wasm）允许在浏览器中运行高性能的二进制代码，未来可能会改变跨域请求的处理方式：

跨域资源的本地处理：通过 Wasm，前端可直接在本地处理跨域加载的资源（如解析跨域的 Excel 文件、处理跨域的图片数据），无需通过 JavaScript 读取资源内容，规避同源策略的限制。

后端逻辑的前端迁移：部分原本需要后端处理的跨域逻辑（如数据验证、加密解密），可迁移到 Wasm 中在前端执行，减少跨域请求的数量，提升响应速度。

虽然目前 Wasm 在跨域场景中的应用还处于早期阶段，但开发者可关注其发展动态，未来可能会成为跨域解决方案的重要补充。

（三）浏览器新特性对跨域的支持

浏览器厂商也在不断推出新特性，简化跨域开发：

Cross-Origin-Opener-Policy（COOP）与
Cross-Origin-Embedder-Policy（COEP）：这两个 HTTP 头用于增强跨域资源的安全性，通过限制跨域窗口的通信和跨域资源的嵌入，防止恶意网站利用跨域漏洞发起攻击。Spring Boot3 开发者可在 CORS 配置中添加这两个头，进一步提升跨域安全性：

// 在CORS过滤器中添加COOP和COEP头
response.setHeader("Cross-Origin-Opener-Policy", "same-origin");
response.setHeader("Cross-Origin-Embedder-Policy", "require-corp");

Origin-Agent-Cluster头：该头用于隔离不同源的资源，防止跨源污染，未来可能会成为浏览器的默认配置，开发者需确保后端的 CORS 响应头兼容该特性。

实战建议与总结

（一）实战建议

优先使用全局 CORS 配置 + Nginx 反向代理：这种组合在安全性、性能和灵活性上达到了平衡 ——Nginx 反向代理减少了跨域请求的数量，全局 CORS 配置统一管理跨域规则，适合大多数生产环境场景。

避免过度依赖@CrossOrigin注解：@CrossOrigin注解仅适合单个接口的临时调试，在多接口、多环境的项目中，容易导致配置混乱，建议统一使用全局配置或自定义过滤器。

定期进行跨域安全审计：使用工具（如 OWASP ZAP、Burp Suite）模拟跨域攻击，检查 CORS 配置是否存在漏洞（如 allowedOrigins 误配置为 * 且 allowCredentials=true、未限制 allowedMethods 导致的方法滥用等）。

记录跨域请求日志：在 CORS 过滤器中记录跨域请求的来源、方法和状态，便于后续排查问题。例如：

log.info("跨域请求处理：来源={}, 方法={}, 处理结果={}", 
         origin, 
         request.getMethod(), 
         origin != null && allowedOrigins.contains(origin) ? "允许" : "拒绝");

跨域问题是前后端分离项目中无法回避的挑战，但并非 “洪水猛兽”—— 只要理解同源策略的本质，掌握 Spring Boot3 的多种跨域解决方案，并结合项目场景选择合适的策略，就能在安全与灵活之间找到平衡。

从开发环境的快速调试，到生产环境的安全配置；从简单的全局 CORS 设置，到复杂的动态白名单 + Security 整合；从传统的 HTTP/2，到未来的 HTTP/3 与 Wasm，跨域解决方案始终在 “适配场景、提升安全、优化性能” 的方向上演进。

对于互联网软件开发人员而言，不仅要掌握具体的配置代码，更要理解背后的安全逻辑和技术趋势 —— 只有这样，才能在面对复杂的跨域场景时，快速定位问题、选择最优方案，为项目构建稳固的跨域通信桥梁。

最后，记住跨域问题的核心原则：“最小权限、动态适配、持续审计”，这十二个字将帮助你在任何跨域场景中都能游刃有余，既保障项目安全，又不影响业务灵活性。