POST请求发送两次？解析CORS预检机制与解决方案-平芜编程栈

1. 问题现象解析：为什么POST请求会发送两次？

当你在浏览器控制台的Network面板中看到同一个POST请求被发送了两次时，这通常意味着发生了以下两种情况之一：

第一次是OPTIONS预检请求（Preflight Request）
第二次才是真正的POST请求

这种机制是浏览器实现跨域资源共享（CORS）安全策略的重要组成部分。当你的前端应用（例如运行在http://localhost:3000）尝试向不同源（例如http://api.example.com）的后端发送POST请求时，如果该请求属于"非简单请求"，浏览器会自动先发送OPTIONS请求进行预检。

2. CORS预检机制深度解析

2.1 什么是简单请求与非简单请求

HTTP请求被分为简单请求和非简单请求两类：

简单请求必须同时满足以下所有条件：

使用GET、HEAD或POST方法
只包含以下自动设置的头部：
- Accept
- Accept-Language
- Content-Language
- Content-Type
Content-Type的值仅限于：
- text/plain
- multipart/form-data
- application/x-www-form-urlencoded

非简单请求的典型特征：

使用PUT、DELETE等非简单方法
包含自定义头部（如Authorization、X-Requested-With等）
Content-Type为application/json
请求中使用了ReadableStream对象

实际开发中，大多数现代API请求（特别是使用JSON格式的）都会触发预检请求，因为它们的Content-Type通常是application/json。

2.2 OPTIONS预检请求的工作原理

当浏览器检测到当前请求是非简单请求时，会自动先发送一个OPTIONS请求到相同URL，这个请求包含以下关键头部：

OPTIONS /api/data HTTP/1.1 Host: api.example.com Origin: http://localhost:3000 Access-Control-Request-Method: POST Access-Control-Request-Headers: content-type,authorization

服务器需要正确响应这个OPTIONS请求，浏览器才会继续发送真正的POST请求。服务器响应示例：

HTTP/1.1 204 No Content Access-Control-Allow-Origin: http://localhost:3000 Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: content-type,authorization Access-Control-Max-Age: 86400

3. 服务端配置解决方案

3.1 基础CORS配置

对于Node.js/Express后端，可以这样配置：

const express = require('express'); const cors = require('cors'); const app = express(); // 基本CORS配置 app.use(cors({ origin: 'http://localhost:3000', methods: ['GET', 'POST', 'PUT', 'DELETE'], allowedHeaders: ['Content-Type', 'Authorization'] })); // 或者更精细的控制 app.use((req, res, next) => { res.header('Access-Control-Allow-Origin', 'http://localhost:3000'); res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE'); res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization'); // 处理OPTIONS预检请求 if (req.method === 'OPTIONS') { return res.sendStatus(204); } next(); });

3.2 预检请求缓存优化

通过设置Access-Control-Max-Age头部，可以指定预检请求的结果能够被缓存多长时间（秒）：

app.use((req, res, next) => { // ...其他CORS头部设置 // 缓存预检请求结果1小时（3600秒） res.header('Access-Control-Max-Age', '3600'); if (req.method === 'OPTIONS') { return res.sendStatus(204); } next(); });

4. 前端开发中的注意事项

4.1 使用axios时的常见问题

当使用axios发送POST请求时，确保正确设置Content-Type：

axios.post('http://api.example.com/data', { key: 'value' }, { headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer token123' } } )

4.2 避免不必要的预检请求

如果可能，尽量将API设计为使用简单请求：

使用application/x-www-form-urlencoded代替application/json
避免添加不必要的自定义头部
使用GET获取数据，POST提交数据

5. 调试与问题排查技巧

5.1 Chrome开发者工具分析

在Chrome的Network面板中：

勾选"Preserve log"保留请求日志
过滤"OPTIONS"请求
检查请求和响应的头部是否符合预期

5.2 常见错误及解决方案

问题1：预检请求失败

现象：OPTIONS请求返回非2xx状态码
解决：确保服务器正确处理OPTIONS方法

问题2：缺少CORS头部

现象：浏览器控制台显示CORS错误
解决：检查服务器响应是否包含必要的Access-Control-Allow-*头部

问题3：凭证模式不匹配

现象：使用withCredentials但Access-Control-Allow-Origin为*
解决：设置具体的origin而非通配符，并添加Access-Control-Allow-Credentials: true

6. 高级话题：预检请求的性能优化

虽然预检请求是必要的安全机制，但在高并发场景下可能影响性能。以下优化策略值得考虑：

合理设置Access-Control-Max-Age：根据应用特点设置适当的缓存时间
API网关统一处理CORS：在网关层统一处理，避免每个微服务重复配置
减少非简单请求的使用：评估是否真的需要PUT/DELETE等方法
预连接技术：使用 rel="preconnect"/> 提前建立连接

7. 幂等性与重复请求

虽然OPTIONS+POST看起来像是发送了两次请求，但需要注意：

OPTIONS请求是只读的，不会改变服务器状态
POST请求是否幂等取决于你的API设计
真正的重复请求问题通常是由于网络重试或用户重复提交导致

确保你的POST API设计考虑幂等性，特别是在支付等关键业务场景中。可以通过以下方式实现：

使用唯一请求ID
实现幂等令牌机制
设计等幂的API逻辑

8. 实际案例：电商网站的购物车API

假设我们有一个电商网站，前端在https://shop.example.com，API在https://api.shop.example.com。

场景：用户添加商品到购物车（需要认证）

前端请求：

fetch('https://api.shop.example.com/cart', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer xyz123' }, body: JSON.stringify({ productId: 123, quantity: 1 }) });

浏览器实际发送的请求序列：

OPTIONS请求到https://api.shop.example.com/cart
- 包含Access-Control-Request-Headers: content-type,authorization
收到204 No Content响应，包含：
- Access-Control-Allow-Origin: https://shop.example.com
- Access-Control-Allow-Headers: content-type,authorization
发送真正的POST请求