预检请求失败主因是服务端未正确响应OPTIONS请求或CORS响应头缺失；需确保返回204/200并包含Access-Control-Allow-Origin、Methods、Headers等必要头，且Headers须精确匹配前端自定义头。
跨域预检请求（Preflight）失败，通常是因为服务端未正确响应 OPTIONS 请求，或请求头/方法不符合 CORS 规范。关键不是前端改 fetch 写法，而是前后端协同解决。
确认是否触发了预检请求
Fetch 只有在满足以下任一条件时才会触发预检（浏览器自动发 OPTIONS）：
- 使用了自定义请求头（如
Authorization、X-Request-ID等） - 请求方法不是
GET、HEAD或POST -
Content-Type值不是text/plain、multipart/form-data或application/x-www-form-urlencoded
例如：fetch(url, { headers: { 'Authorization': 'Bearer xxx' } }) 必然触发预检；而纯 GET 请求一般不会。
服务端必须正确响应 OPTIONS 请求
预检失败的主因是后端没处理 OPTIONS，或响应缺少必要 CORS 头。服务端需确保：
立即学习“Java免费学习笔记（深入）”；
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 对
OPTIONS请求返回204 No Content或200 OK - 响应头包含：
Access-Control-Allow-Origin（不能为*当带凭证时）、Access-Control-Allow-Methods、Access-Control-Allow-Headers、Access-Control-Allow-Credentials（如需 cookies） -
Access-Control-Allow-Headers必须明确列出前端实际发送的自定义头（如Authorization、Content-Type）
常见错误：后端只写 Access-Control-Allow-Origin: *，但没配 Allow-Headers，导致预检被浏览器拒绝。
前端可优化但不能绕过预检
前端能做的有限，但可减少不必要触发：
- 避免无意义的自定义 header，比如不用
X-Requested-With - 用标准
Content-Type（如application/json会触发预检；application/x-www-form-urlencoded不会） - 如无需认证，暂时去掉
credentials: 'include'或Authorization头测试是否预检消失 - 调试时用浏览器 Network 面板看是否发出
OPTIONS请求，以及它的响应头是否完整
开发环境临时绕过（仅限调试）
生产环境绝不能依赖此方式，但本地开发可：
- 启动浏览器时加参数禁用 CORS（如 Chrome：
--disable-web-security --user-data-dir=/tmp），仅用于快速验证逻辑 - 用本地代理（如 Webpack DevServer 的
proxy、Vite 的server.proxy）把请求转发到后端，让请求变成同源 - 后端开启本地跨域支持（如 Express 加
cors()中间件并配置好 origin 和 credentials）
注意：这些只是辅助手段，根本解法仍是服务端正确实现 CORS 预检响应。
