POST 会发送两次请求吗？

①结论先行：先分清你说的是哪种「两次」

②为什么会有这些「两次」：根因各不相同

③CORS 预检：最常见的那个「两次」

浏览器对跨域请求有一套安全机制。如果请求属于「非简单请求」，浏览器会先自动发一个 OPTIONS 请求问服务器：「我准备用 POST + JSON + 自定义头去访问你，你允许吗？」只有服务器明确许可，真正的 POST 才会发出。

什么叫「简单请求」（不触发预检）

必须同时满足以下三条，缺一条就触发预检：

完整时序

④交互：你的请求会触发预检吗

调整下面四个条件，实时判断是否会多出一次 OPTIONS 请求：

⑤Expect: 100-continue：一次请求，分两趟走

这是「POST 发两次」说法的第二大来源，也是被误传最广的一个。客户端在请求头里带上 Expect: 100-continue，意思是：「我先只发请求头，你确认能收，我再发 body」——目的是避免白传几百 MB 的文件。

⑥重定向：唯一让 POST 真的发两次的「正规」机制

这是最需要警惕的一类。HTTP 不同状态码对「重定向时是否保留方法与请求体」的规定完全不同：

⑦网关重试：Nginx 到底会不会重发 POST

这是后端最常背锅的一类。结论先说：Nginx 从 1.9.13 起，默认不会对「已经发出去的」POST 请求重试。

# 默认值：只在 error / timeout 时换节点
proxy_next_upstream error timeout;

# 想让 500 / 502 / 503 也换节点（注意：对已发出的 POST 仍然不重试）
proxy_next_upstream error timeout http_500 http_502 http_503;

# ⚠️ 危险：加上 non_idempotent 才会对 POST / LOCK / PATCH 重试
#    一旦开启，超时或 500 时 POST 会真的发第二次 → 可能重复下单
proxy_next_upstream error timeout http_500 non_idempotent;

# 同时建议限制重试次数与总时长
proxy_next_upstream_tries 2;
proxy_next_upstream_timeout 10s;

⑧客户端与用户侧：代码与手指造成的两次

// 反例：StrictMode 下会跑两次，POST 也就发了两次
useEffect(() => {
  fetch('/api/track', { method: 'POST', body: ... });  // 副作用写在 effect 里
}, []);

// 正解一：加清理函数（AbortController 取消请求）
useEffect(() => {
  const ac = new AbortController();
  fetch('/api/track', { method: 'POST', signal: ac.signal });
  return () => ac.abort();
}, []);

// 正解二：axios-retry 明确只对幂等方法重试
axiosRetry(axios, {
  retries: 3,
  retryCondition: (err) => err.code === 'ECONNABORTED',
  // 关键：只重试 GET，绝不重试 POST
  shouldResetTimeout: true,
});

⑨看起来像两次，其实不是

⑩排查清单：怎么判断我属于哪一种

1. 看 DevTools 的 Method 列：一条是 OPTIONS 一条是 POST → CORS 预检（正常，POST 只发一次）。
2. 两条都是 POST 且 URL 不同 → 307/308 重定向。看第一条的响应状态码是不是 307/308。
3. 两条都是 POST 且 URL 相同 → 看后端日志的 upstream IP：不同 = 网关重试；相同 = 客户端重试或用户重复提交。
4. 看时间间隔：＜100ms 倾向于网关/客户端自动重试；＞300ms 倾向于用户双击或代码里发了两次。
5. 只在开发环境出现 → 高度怀疑 React StrictMode 或热更新重复执行。
6. 只有 curl / 后端调用出现，浏览器没有 → 查 Expect: 100-continue 与 curl 的自动重试。
7. 生产偶发、压测时变多 → 查网关的 proxy_next_upstream 是否包含 non_idempotent，以及超时配置是否过短。

# 用 curl 观察到底发了几次、发的什么
curl -v -X POST https://api.example.com/order \
  -H 'Content-Type: application/json' \
  -d '{"skuId":123,"num":1}'

# 输出里重点看：
#   > Expect: 100-continue   ← 是否分两趟发
#   < HTTP/1.1 100 Continue ← 服务器的确认
#   < HTTP/1.1 307          ← 是否发生保方法重定向
#   < location: https://... ← 重定向目标

⑪根本解法：让 POST 幂等

无论上面哪种原因导致重复，最可靠的防线永远是服务端的幂等设计——因为网络不可靠，重复请求无法 100% 避免，只能让它「重复了也没关系」。

⑫误区与面试速记

一句话速记