@CrossOrigin未生效的根本原因是注解未正确加载，常见于加在非Controller类、被AOP拦截、或Spring MVC未扫描到该类；需确保加在@RestController/@Controller上，且注意与全局配置、Spring Security的协同关系。
为什么 @CrossOrigin 加了但浏览器还是报 CORS 错误
常见现象是加了 @CrossOrigin 注解，接口能正常返回数据，但浏览器控制台仍提示 No 'Access-Control-Allow-Origin' header is present。根本原因通常是：注解没生效——比如加在了非 Controller 方法上、被 AOP 代理拦截（如 @Transactional 在同一类内调用）、或者 Spring MVC 没扫描到该类。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
@CrossOrigin必须加在@RestController或@Controller标记的类或方法上，不能加在 Service 层 - 若类上已加
@CrossOrigin，方法上再加会覆盖类级配置；反之方法级优先级更高 - 检查是否启用了 WebMvcConfigurationSupport 自定义配置——它会关闭 Spring Boot 默认的
CorsConfiguration自动注册，导致注解失效 - 确认请求路径与注解指定的
origins完全匹配（"*"不支持带凭证的请求，需显式写域名）
全局配置 CorsFilter 时，addMapping("/**") 为什么没生效
典型错误是把 CorsConfigurationSource bean 和 CorsFilter bean 混用，或在 WebSecurityConfigurerAdapter 中错误地禁用了 CORS（如调用了 http.cors().disable()）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- Spring Boot 2.4+ 推荐用
@Bean返回CorsConfigurationSource，而非手动 newCorsFilter；后者容易绕过 Spring Security 的过滤链顺序 -
addMapping("/**")要配在UrlBasedCorsConfigurationSource上，且必须在WebMvcConfigurer的addCorsMappings方法里注册，否则只是个未挂载的配置对象 - 如果同时用了 Spring Security，必须显式启用 CORS：
http.cors(Customizer.withDefaults())，否则 Security 过滤器会提前拒绝预检请求（OPTIONS） - 注意路径匹配逻辑：Spring MVC 的
/**匹配所有路径，但 Spring Security 的antMatchers若写了/api/**，而前端发的是/v1/api/xxx，就可能漏匹配
@CrossOrigin 和全局配置冲突时，谁起作用
不是“谁覆盖谁”，而是两套机制在不同阶段介入：注解由 RequestMappingHandlerMapping 解析，在 DispatcherServlet 分发前注入配置；全局配置（如 WebMvcConfigurer.addCorsMappings）生成的是全局默认策略，仅对未显式标注 @CrossOrigin 的端点生效。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 一个接口同时有
@CrossOrigin和全局配置 → 注解优先，全局配置被忽略 - 全局配置中设置了
allowedOrigins = ["https://a.com"]，但某个方法加了@CrossOrigin(origins = "*")→ 该方法允许任意源，其他方法仍受全局限制 - 若全局配置里设了
allowCredentials = true，但某个@CrossOrigin没设，那该方法仍不允许带 cookie —— 因为allowCredentials无法继承，必须显式声明 - 跨域头最终由
CorsProcessor写入响应，它只读取当前请求匹配到的唯一CorsConfiguration，不会合并多个来源
生产环境别直接用 origins = ["*"] 的真实原因
表面上是安全策略问题，实际更关键的是：Chrome 123+ 和 Safari 17+ 已强制要求，当响应头含 Access-Control-Allow-Credentials: true 时，Access-Control-Allow-Origin 不得为 "*"，否则直接抛 CORS error，连预检都过不去。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 开发期可临时用
@CrossOrigin(origins = "*")，但上线前必须替换为具体域名列表，如["https://app.example.com", "https://staging.example.com"] - 若前端部署在多子域（如
a.example.com,b.example.com），不能靠通配符"*.example.com"—— CORS 规范不支持域名通配符，只能逐个列出或后端动态解析Origin请求头做白名单校验 - 动态白名单示例逻辑：在
CorsConfigurationSource中取出request.getHeader("Origin")，判断是否在预设集合内，再构造CorsConfiguration；注意要处理空 Origin 和恶意伪造
真正麻烦的不是配错，而是线上环境混合了 Nginx 反向代理、CDN、多个前端部署域名，以及浏览器版本碎片化——这时候光看 Spring 配置没用，得抓包确认最终响应头里到底有没有、写没写对、顺序对不对。
