Sa-Token跨域避坑指南：为什么你的CORS配置还是不生效？

Sa-Token跨域实战：从原理到避坑的完整解决方案

跨域问题就像开发路上的隐形路障，看似简单却总在关键时刻绊住脚步。最近在技术社区看到不少开发者反馈Sa-Token的CORS配置"明明按文档写了却依然不生效"，这背后往往隐藏着对浏览器安全机制和框架特性的双重误解。本文将带你穿透表象，直击Sa-Token跨域配置的七个关键雷区，并提供可立即落地的解决方案。

1. 跨域的本质与Sa-Token的定位误区

很多开发者第一反应是"后端没配置好"，但跨域本质是浏览器实施的安全沙箱策略。当你的前端页面（如http://localhost:8080）尝试访问后端API（如http://api.example.com）时，浏览器会：

1. 先发送OPTIONS预检请求探路
2. 检查响应头是否符合安全策略
3. 决定是否放行真实请求

常见误区：在Sa-Token配置类中直接这样写：

@Bean
public SaCorsHandleFunction corsHandle() {
    return (req, res, sto) -> {
        res.setHeader("Access-Control-Allow-Origin", "*");
    };
}

这种写法在简单场景下可能有效，但遇到以下情况就会失效：

• 需要携带认证信息（如satoken）
• 使用非简单请求（如Content-Type为application/json）
• 浏览器升级了安全策略

2. 预检请求处理的关键细节

OPTIONS请求是浏览器发出的"探路石"，但很多开发者会忽略这些细节：

// 错误示例：遗漏OPTIONS处理
@Bean
public SaCorsHandleFun