RuntimeException无法拦截跨域请求，因跨域由浏览器同源策略控制，预检失败时Java后端根本不会执行；正确做法是配置CORS白名单、用Filter校验Origin头、结合Spring Security做权限认证。
java 中无法通过 runtimeexception “快速拦截”跨域请求变量访问——这不是 runtimeexception 的职责，也不符合跨域（cors）问题的本质。跨域是浏览器的同源策略限制，发生在前端发起 http 请求时，后端 java 代码根本收不到非法跨域请求的“变量访问”，更不会因此抛出 runtimeexception。
跨域问题不在 Java 运行时异常层面
浏览器在发送跨域请求前会先发一个 OPTIONS 预检请求，只有预检通过（服务端返回合法 CORS 响应头），浏览器才会发送真正的 GET/POST 等请求。如果服务端没配 CORS，浏览器直接阻断，Java 后端压根不会执行 Controller 方法，也就没有“变量访问”可拦截，更不会触发 RuntimeException。
所以： • 不是 Java 抛异常阻止跨域，而是浏览器主动拒绝； • RuntimeException 是业务逻辑异常，不是安全网关； • 想“拦截未授权访问”，该用的是权限控制或网关过滤，不是 try-catch RuntimeException。
真正有效的拦截方式：CORS 配置 + 权限校验
如果你发现某些跨域请求“绕过了预期限制”，说明问题出在服务端配置或认证缺失，而非异常机制。正确做法是：
-
显式配置 CORS 白名单：禁用
allowedOrigins = ["*"]（尤其含凭证时），改用具体域名，如["https://admin.example.com"]； -
结合 Spring Security 或自定义 Filter 校验 Origin 头：在请求进入 Controller 前，检查
request.getHeader("Origin")是否在许可列表中，不匹配则直接返回 403； -
对敏感接口强制认证：即使跨域允许，也要验证 Token、Session 或权限注解（如
@PreAuthorize("hasRole('ADMIN')")），这才是真正的“未授权拦截”； - 避免在业务代码里 throw RuntimeException 来“模拟拦截”：这会导致错误状态码（500）、日志污染、掩盖真实问题，且无法阻止预检失败的请求。
一个常见误解场景与修正
比如你写了这样的 Controller：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
@GetMapping("/api/data")
public String getData() {
String origin = request.getHeader("Origin");
if (!"https://trusted.com".equals(origin)) {
throw new RuntimeException("Unauthorized origin"); // ❌ 错误做法
}
return "sensitive data";
}
问题在于：
• 如果前端来自 https://hacker.com，浏览器可能连 OPTIONS 都不发（取决于请求是否简单），或者发了但服务端没配 CORS 响应头，直接失败；
• 即使发了真实请求，这段代码也只在“预检已通过”的前提下才执行——而预检通过恰恰说明你已错误地开放了宽泛 CORS（比如用了 "*"）；
• 抛 RuntimeException 返回 500，既非标准拒绝语义，也无法让前端明确知道是“跨域被拒”，还暴露服务端细节。
✅ 正确写法是移除该判断，在 Filter 或 WebMvcConfigurer 中统一管控 Origin，并配合认证。
立即学习“Java免费学习笔记（深入）”；
总结：别让 RuntimeException 背锅
CORS 是协议层、网关层、配置层的问题，不是 Java 异常处理能解决的。想防御未授权跨域访问，核心是： • 正确配置 CORS（最小化 origin、关闭 credentials 除非必要）； • 使用 Filter/Interceptor 在请求早期校验来源和身份； • 敏感数据接口必须依赖认证鉴权框架，而非运行时异常兜底。
