该方案通过@crosscheck注解与反射实现轻量级跨域跨页请求校验，仅对标注接口生效，基于origin、referer、预检头三要素精准拦截不合规请求，不侵入业务且无需网关。
直接用注解 + 反射在自研微服务框架里拦截不合规跨域、跨页请求，核心不是“拦住所有”，而是精准识别并阻断那些既没带合法 Origin 又没走预检（或预检失败）、且目标页面非同源白名单的请求。关键在请求入口处做轻量级校验，不侵入业务逻辑，也不依赖网关层。
一、定义 @CrossCheck 注解，标记需要校验的 Controller 方法
不全局拦截，只对明确需要跨页/跨域访问的接口加约束。比如管理后台跳转、嵌入式 iframe 页面、第三方回调等场景。
- 注解支持配置白名单域名（支持通配符 *）、是否允许携带凭证（withCredentials）、允许的 HTTP 方法
- 示例：@CrossCheck(allowOrigins = {"https://admin.example.com", "https://*.partner.com"}, allowCredentials = true)
- 注解保留策略设为 RUNTIME，确保反射可读取
二、写一个 RequestInterceptor，用反射提取注解并校验请求头
在 Spring MVC 的拦截器或自研框架的 Filter 链中插入校验逻辑。重点不是重写整个 CORS 流程，而是复用已有的 Origin、Referer、Access-Control-Request-Method 等字段做快速判断。
- 通过 request.getAttribute(HandlerMapping.BEST_MATCHING_HANDLER) 获取当前执行的 HandlerMethod
- 反射调用 handlerMethod.getMethod().getAnnotation(CrossCheck.class) 拿到配置
- 校验三要素：Origin 是否匹配白名单、Referer 是否为空或非法跳转、预检请求中 Access-Control-Request-Method 是否在允许范围内
- 不合规时直接返回 403，并写明原因（如 “Origin not allowed” 或 “Missing valid Referer”）
三、处理预检请求（OPTIONS）要特别小心
浏览器发预检是无 Cookie、无 body 的纯头请求，但很多自研框架默认不把 OPTIONS 转给 Controller，导致注解拿不到。必须提前在拦截器里识别并放行或响应。
- 在拦截器开头判断 request.getMethod().equals("OPTIONS")
- 若目标方法有 @CrossCheck 注解，就立即构造响应头：Access-Control-Allow-Origin、Allow、Access-Control-Allow-Methods 等，不往下走业务链
- 避免让 OPTIONS 进入 Controller 层——否则可能触发空指针或重复校验
四、Referer 校验不是银弹，得配合页面级白名单
单纯校验 Referer 容易被绕过，所以只作为辅助手段：当 Origin 缺失或为 null（比如从本地文件打开、某些 WebView 场景），就查 Referer 是否来自可信管理页或合作方落地页。
- 维护一个内存 Map 或配置中心加载的 List
refererWhitelist - 匹配时用 startsWith 或正则（如 https://admin\.example\.com/.*），不依赖完整 URL 相等
- 注意：移动端 WebView、Electron 应用可能不带 Referer，这类需单独走 token 或签名机制，不在本注解覆盖范围
这套方案不依赖外部组件，不改动现有路由和序列化逻辑，上线后可通过日志埋点统计拦截次数和来源分布，后续再结合 UA、IP 段做分级管控。真正难的不是写反射，而是厘清哪些请求该放、哪些该拦、边界在哪。
