从实战出发，拆解OPTIONS预检请求的‘是与非’

1. 为什么你的POST请求突然多了一个"小弟"？

最近在调试一个前后端分离项目时，我发现一个有趣的现象：明明只写了一个POST请求，浏览器却悄悄多发了一个OPTIONS请求。这就像你约朋友吃饭，结果对方先派了个助理来问："我家老板能吃辣吗？对海鲜过敏吗？"——这个助理就是OPTIONS预检请求。

第一次看到这个现象时，我也很困惑。后来发现，这其实是浏览器的一种安全机制。当你的前端应用（比如运行在http://localhost:3000）尝试访问另一个域名（比如https://api.example.com）的接口时，浏览器会先派OPTIONS请求去"探路"。

关键区别在于：

• 简单请求：直接放行，不需要"探路"
• 非简单请求：必须先发OPTIONS预检

2. 简单请求 vs 非简单请求的实战对比

2.1 什么样的请求算"简单"？

浏览器对"简单请求"有严格定义，必须同时满足以下条件：

1. HTTP方法限制：只能是GET、HEAD或POST
2. 头部字段限制：只能包含以下字段：
   • Accept
   • Accept-Language
   • Content-Language
   • Content-Type
3. Content-Type限制：只能是以下三种之一：
   • application/x-www-form-urlencoded
   • multipart/form-data
   • text/plain

来看个实际例子：

javascript复制// 这是一个简单请求
fetch('https://api.example.com/data', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded'
  },
  body: 'name=张三&age=25'
})

打开浏览器开发者工具，你会看到只有一个POST请求，没有OPTIONS预检。

2.2 什么情况下会触发预检？

只要打破上述任一条件，就会变成"非简单请求"。常见场景包括：

1. 使用PUT、DELETE等方法
2. 发送JSON数据（Content-