处理带预检的复杂跨域请求，关键在于前后端协同完成options预检：满足非简单方法、自定义头、非三类content-type或携带凭证任一条件即触发；服务端须对options路径显式响应204并设置正确cors头，前端可优化减少预检。
处理带预检的复杂跨域请求，关键不在前端“绕过”限制，而在于让浏览器和服务器达成一致：先通过 OPTIONS 预检确认安全，再放行主请求。只要前后端配合得当，这类请求完全可稳定运行。
哪些请求会触发预检（OPTIONS）
浏览器自动判断，满足任一条件即发起预检：
- 使用 PUT、DELETE、PATCH、HEAD 以外的非简单方法（如 fetch 配置 method: 'PUT'）
- 设置了自定义请求头，例如 X-Tracker-ID、Authorization、X-Version
- Content-Type 不是以下三者之一：application/x-www-form-urlencoded、multipart/form-data、text/plain（比如发 JSON 时设为 application/json）
- 携带 Cookie 或其他凭证，即 fetch 中设置了 credentials: 'include'
服务端必须正确响应 OPTIONS 请求
预检失败，主请求根本不会发出。后端需对所有统计/上报接口的 OPTIONS 路径 做显式处理，推荐返回 204 No Content，并设置以下响应头：
- Access-Control-Allow-Origin：不能填 *（因 credentials: 'include' 要求），应写具体域名，如 https://your-site.com；多端可用白名单动态匹配
- Access-Control-Allow-Methods：至少包含主请求所用方法，如 POST, OPTIONS
- Access-Control-Allow-Headers：列出前端实际发送的 header，如 Content-Type, X-Tracker-ID, Authorization
- Access-Control-Allow-Credentials：值必须为 true（与前端 credentials 严格对应）
- Access-Control-Max-Age（可选）：设为 86400 可缓存预检结果 24 小时，减少重复 OPTIONS
前端可做的合理优化
不是所有复杂请求都不可简化。在不影响业务的前提下，可降低预检频率：
- 上报数据改用 URLSearchParams 构造表单体，Content-Type 保持 application/x-www-form-urlencoded，避免触发预检
- 移除非必要自定义 header，如调试用的 X-Debug，上线环境只保留必需字段
- 若无需用户上下文，不设 credentials: 'include'，此时 Access-Control-Allow-Origin 可用 *，配置更宽松
- 确保 fetch 或 axios 的 URL 是完整路径（含协议+域名），避免相对路径引发 Origin 不一致
排查常见卡点
控制台报 preflight is invalid 或 net::ERR_FAILED，通常不是代码写错，而是这些细节漏了：
- 后端只给 POST 接口加 CORS 头，但忘了单独处理同路径的 OPTIONS 请求
- 反向代理（如 Nginx）拦截了 OPTIONS，未透传或未配置 allowed_methods
- 服务端路由中间件顺序错误，CORS 头被后续逻辑覆盖或未执行
- 预检响应状态码不是 200 或 204（例如返回了 302 重定向，CORS 规范明确禁止）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
