预检请求失败的核心是options响应缺失或错误的关键cors头；必须在network面板中定位options请求，检查access-control-allow-origin、methods、headers三项是否齐全且值正确，缺一或错一则预检失败。
预检请求失败，核心是浏览器没看到它想看的响应头。排查重点不在“有没有发请求”，而在“OPTIONS 响应里缺了什么、写错了什么”。直接打开开发者工具 Network 面板，找到那个 Method: OPTIONS 的请求，点开它的 Response Headers，逐项核对是否齐全、是否匹配。
看准那个 OPTIONS 请求
很多人误以为在主请求（比如 PUT 或带 Authorization 头的 GET）里查响应头——这是错的。预检失败时，主请求根本不会发出。必须定位到 Network 中第一个 Method 为 OPTIONS 的条目，且状态码通常是 200、204，也可能是 4xx 或 5xx。如果连这个 OPTIONS 请求都没出现，说明前端请求本身不触发预检（比如只是简单 GET），问题另在他处。
检查三项关键响应头是否都存在且值正确
浏览器只认这三组头，少一个或写错一个，预检就挂：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
Access-Control-Allow-Origin：必须精确匹配前端 Origin（如
http://localhost:3000），不能是*（除非没带 credentials） -
Access-Control-Allow-Methods：必须包含你实际要用的 HTTP 方法，比如前端发的是 DELETE，这里就得有
DELETE；多个方法用英文逗号+空格分隔（GET, POST, DELETE） -
Access-Control-Allow-Headers：必须列出前端所有自定义请求头（如
X-Auth-Token、X-Request-ID），以及Content-Type（即使它是默认值）。注意大小写不敏感，但拼写必须一致
留意中间件和重定向干扰
很多预检失败不是配置漏了，而是被其他逻辑吞掉了：
- 反向代理（如 Nginx）或网关中间件可能拦截了 OPTIONS 请求，没转发给后端，自己返回了 405 或空响应
- 身份认证中间件（如 JWT 校验）在 OPTIONS 阶段也执行，结果因缺少 token 返回 401，导致预检失败
- 服务器对 OPTIONS 返回了 301/302 重定向——CORS 规范明确禁止预检阶段重定向，浏览器会直接拒绝
快速验证：用 curl 模拟预检请求
绕过浏览器，直连后端验证响应头是否真的发出来了：
curl -I -X OPTIONS \ -H "Origin: http://localhost:3000" \ -H "Access-Control-Request-Method: PUT" \ -H "Access-Control-Request-Headers: X-Auth-Token, Content-Type" \ https://your-api.com/api/item观察返回的 Header，确认 Access-Control-Allow-Origin 等字段是否完整、值是否合理。这样能排除前端代码或浏览器缓存干扰。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
