预检请求头包括哪些

在日常开发中，前后端分离架构越来越普遍，跨域请求成了绕不开的话题。当你用前端调用一个不同域名的接口时，浏览器可能会自动发起一个 OPTIONS 请求，也就是常说的“预检请求”（Preflight Request）。这个请求的目的，是确认服务器是否允许接下来的实际请求。而预检请求里携带的请求头，直接决定了服务器能否通过安全检查。

什么情况下会触发预检请求

并不是所有请求都会触发预检。只有当请求满足“非简单请求”的条件时，浏览器才会提前发个 OPTIONS 探探路。比如你发送了自定义头部、使用了 PUT 或 DELETE 方法、或者 Content-Type 是 application/json 以外的类型，这时候预检就来了。

常见的预检请求头字段

预检请求中，最关键的几个请求头是下面这几个：

Access-Control-Request-Method：告诉服务器接下来的实际请求会使用哪种 HTTP 方法，比如 PUT、DELETE 等。
Access-Control-Request-Headers：列出实际请求中会包含的自定义请求头，比如 Authorization、X-Requested-With 等。
Origin：虽然不是预检独有，但每次跨域请求都会带上，表示请求来自哪个源。

举个例子，前端代码中设置了 Authorization 头来传递 token：

fetch('https://api.example.com/data', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer xxxxx'
  },
  body: JSON.stringify({ id: 1 })
})

由于带了自定义头 Authorization，浏览器就会先发一个 OPTIONS 请求，其中包含：

OPTIONS /data HTTP/1.1
Host: api.example.com
Origin: https://myapp.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization

服务器收到后，需要检查这些头是否被允许。如果后端配置了 CORS，并明确允许 POST 方法和 authorization 头，就会返回对应的响应头，比如 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers，浏览器才会继续发送真正的 POST 请求。

后端如何应对预检请求

有些后端框架会自动处理 OPTIONS 请求，但更多时候需要手动配置。比如在 Node.js 的 Express 中，可以这样加个中间件：

app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', 'https://myapp.com');
  res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  
  if (req.method === 'OPTIONS') {
    res.sendStatus(200);
  } else {
    next();
  }
});

这里的关键是把预检请求需要的信息都返回去，尤其是 Allow-Headers 要和请求里的 Access-Control-Request-Headers 对得上，不然预检失败，真正的请求压根不会发出。

运维过程中，经常会遇到前端说“接口调不通”，一查网络面板才发现卡在 OPTIONS 上。这时候别急着查业务逻辑，先看看预检请求的头有没有对齐，服务器有没有正确响应。很多时候问题就出在这几个头的拼写大小写不一致，比如前端传的是 Authorization，后端却只允许 authorization，结果就被拦下了。

预检请求头包括哪些 使用技巧与常见问题解析