自定义注解不能直接反射设置CORS头，因其仅为元数据；真正起作用的是配套的AOP切面、Filter或Spring CORS机制，注解仅作标记和参数传递。
自定义注解本身不能直接“反射配置cors头信息”，因为cors响应头（如 access-control-allow-origin）必须在http响应阶段由servlet容器或spring mvc拦截机制写入，而java注解（如 @interface）只是元数据，不具备执行能力。真正起作用的是配合注解使用的aop切面、过滤器（filter）或spring的cors注册机制——注解仅作标记和参数传递用。
注解只负责声明，真正干活的是配套的处理逻辑
比如定义一个 @EnableCorsForRole(role = "ADMIN") 注解，它本身不会设置任何响应头。你需要额外做三件事：
- 编写一个
@Aspect切面或Filter，在请求进入时扫描该注解 - 通过
ProceedingJoinPoint或HttpServletRequest获取当前方法/类上的注解实例 - 根据注解属性（如
role）动态决定是否放行，并调用HttpServletResponse.setHeader()写入CORS头
为什么不能靠“反射注解”自动加CORS头
Spring的CORS机制是基于请求路径匹配和预设策略的，不是运行时靠反射读取每个方法注解再拼响应头。浏览器的预检（OPTIONS）请求发生在Controller方法执行前，此时Spring已通过 CorsConfiguration 或 @CrossOrigin 提前完成头注入。若试图在AOP环绕通知里手动 setHeader，可能因响应已提交而失效，尤其对OPTIONS请求无效。
安全校验应与CORS分离设计
跨域控制（CORS）和权限校验（如token、角色）属于不同层级的安全关注点：
- CORS解决的是“谁可以发请求”：控制前端域名、方法、头字段能否发起跨域调用（属浏览器策略）
- 注解校验解决的是“谁可以访问资源”：验证token有效性、用户角色、业务规则等（属服务端鉴权）
强行把二者耦合进同一个注解，容易导致逻辑混乱、调试困难，也违背单一职责原则。推荐做法是：
- 用
@CrossOrigin或全局CorsConfiguration统一管理跨域白名单 - 用自定义注解（如
@RequireRole("ADMIN")）配合AOP做权限拦截 - 若需差异化CORS策略（如某接口只允许特定域名+带凭证），应通过
CorsConfigurationSource编程式注册，而非注解反射
真正可行的轻量级方案示例
若坚持用注解驱动CORS行为，可参考以下结构：
（不推荐生产直接使用，仅说明原理）- 定义注解：
@Target(METHOD) @Retention(RUNTIME) @Documented public @interface DynamicCors { String origin() default "*"; boolean allowCredentials() default false; } - 实现一个
HandlerInterceptor，在preHandle中解析该注解，匹配当前请求路径 - 调用
response.setHeader("Access-Control-Allow-Origin", origin)等，并显式设置Access-Control-Allow-Credentials - 注意：必须确保该拦截器在Spring内置CORS处理器之前执行，且对OPTIONS请求也生效
但这种方式绕过了Spring CORS的标准流程，失去对 maxAge、allowedHeaders 等高级特性的自动支持，维护成本高。
