浏览器在满足特定条件时自动触发OPTIONS预检请求，而非JavaScript主动发起；触发条件包括：使用非GET/HEAD/POST方法、设置自定义请求头、Content-Type非text/plain/multipart/form-data/application/x-www-form-urlencoded三者之一。
JavaScript 本身不直接发起 OPTIONS 预检请求，这是浏览器在特定条件下自动触发的机制。你无法用 fetch 或 XMLHttpRequest 主动“发送一个 OPTIONS 请求来测试跨域权限”——浏览器只在满足预检条件时，才在真正请求前自动发 OPTIONS，并根据响应头（如 Access-Control-Allow-Origin、Access-Control-Allow-Methods 等）决定是否放行后续请求。
什么情况下会触发预检？
当你的前端请求满足以下任一条件时，浏览器会在发主请求前自动加一次 OPTIONS 预检：
- 使用了除
GET、HEAD、POST以外的请求方法（如PUT、DELETE、PATCH） - 设置了自定义请求头（如
Authorization、X-Request-ID、My-Custom-Header） -
Content-Type值不是以下三种之一：text/plain、multipart/form-data、application/x-www-form-urlencoded
如何判断是否发生了预检？
打开浏览器开发者工具 → Network 标签页，发起请求后观察：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 如果看到两个请求：第一个是 OPTIONS（状态码 200 或 204），第二个才是你的实际请求（如 POST），说明触发了预检
- 点击 OPTIONS 请求 → 查看 Response Headers，关键字段包括：
Access-Control-Allow-Origin（必须匹配或为 *）
Access-Control-Allow-Methods（需包含你用的请求方法）
Access-Control-Allow-Headers（需包含你设置的所有自定义头）
Access-Control-Allow-Credentials（若带 cookie，此项必须为 true，且Access-Control-Allow-Origin不能为 *）
后端必须正确响应 OPTIONS 请求
预检失败的根本原因几乎都在服务端。后端需确保：
立即学习“Java免费学习笔记（深入）”；
- 对所有
OPTIONS请求返回 200 或 204 状态码（不能重定向或报错） - 响应头中明确声明允许的源、方法、头字段，且值要精确匹配前端所用内容
- 例如前端发
PUT+Authorization+Content-Type: application/json，后端 OPTIONS 响应至少要有：Access-Control-Allow-Methods: GET, POST, PUT, DELETEAccess-Control-Allow-Headers: Content-Type, AuthorizationAccess-Control-Allow-Origin: https://your-frontend.com
绕过预检的实用建议
如果只是调试或内部系统，可考虑简化请求以避免预检：
- 用
POST模拟其他操作（如 body 里传{"action": "delete"}） - 避免自定义请求头；如需鉴权，优先用 Cookie（配合
credentials: 'include'）而非Authorization头 - 保持
Content-Type为application/x-www-form-urlencoded或text/plain（但注意 JSON 数据需手动序列化为字符串再发）
