HTTP 有哪些请求方法？什么是安全性和幂等性？

简化版

常见方法有 GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS。两个关键概念：安全性——该方法不改变服务器状态（只读），如 GET/HEAD/OPTIONS；幂等性——同样的请求执行一次和执行多次效果相同，如 GET/PUT/DELETE。POST 既不安全也不幂等（重复提交会重复创建），这也是「重复下单」问题的根源。

详细版

常见请求方法：

方法	作用	安全	幂等
GET	获取资源	✅	✅
HEAD	只取响应头，不要 body	✅	✅
OPTIONS	查询支持的方法/CORS 预检	✅	✅
POST	提交/新建资源	❌	❌
PUT	全量更新/替换资源	❌	✅
DELETE	删除资源	❌	✅
PATCH	局部更新资源	❌	不保证

• 安全性（Safe）：调用后不改变服务器资源状态——纯读操作。GET、HEAD、OPTIONS 是安全的。
• 幂等性（Idempotent）：同一个请求发一次和发 N 次，服务器最终状态一致。GET、HEAD、OPTIONS、PUT、DELETE 幂等；POST 不幂等；PATCH 不保证。

完整版教学

一、安全性：会不会改数据

「安全」在 HTTP 语境里不是指「加密防窃听」，而是指**「这个方法会不会改变服务器状态」**。

• 安全方法（GET、HEAD、OPTIONS）：只读，调用多少次都不改数据。所以浏览器可以放心地预取、缓存、被爬虫抓取 GET 请求——反正不会有副作用。
• 非安全方法（POST、PUT、DELETE、PATCH）：会改数据，不能随意重复或预取。

这就是为什么规范要求：别用 GET 去做删除/修改。如果把删除做成 GET /deleteUser?id=1，浏览器预取、爬虫抓取、或用户不小心刷新，都可能悄悄触发删除，酿成事故。

二、幂等性：重复执行结果一样吗

幂等性指同样的请求执行一次和多次，对服务器的最终影响相同。逐个看：

• GET：查询多次，数据不变，幂等 ✅
• PUT：PUT /users/1 把用户 1 整体替换成某个值，执行一次和执行三次，结果都是那个值，幂等 ✅
• DELETE：DELETE /users/1 删一次和删三次，最终状态都是「用户 1 不存在」，幂等 ✅（第二次返回 404 不影响「资源已删除」这个最终状态）
• POST：POST /users 提交三次，可能创建三条记录，不幂等 ❌
• PATCH：PATCH 做局部更新，是否幂等取决于操作——{age: 18} 幂等，但 {age: age+1}（相对修改）不幂等，所以规范上不保证幂等。

关键理解：幂等看的是「服务器最终状态」，不是「每次返回是否相同」。DELETE 第二次返回 404，但资源都是「不存在」，最终状态一致，所以幂等。

三、为什么幂等性在工程上如此重要

幂等性不是纯理论，它直接关系到重试和重复提交的安全：

• 网络重试：请求超时了，客户端/网关不知道服务器到底处理没处理，要不要重试？如果接口是幂等的，重试就是安全的（多执行一次没关系）；如果不幂等（如 POST 下单），重试可能造成重复扣款、重复下单。
• 重复提交：用户手抖点两次「提交订单」，不幂等的 POST 会创建两个订单。

所以对「创建/支付」这类非幂等操作，要额外做幂等设计：用幂等 token（提交前先申请一个唯一 token，服务端用它去重）、数据库唯一约束、状态机等，保证「重复请求只生效一次」。这是分布式系统和支付场景的高频考点。

四、PUT vs POST：什么时候用哪个

两者都能「提交数据」，区别在幂等和语义：

• POST：用于创建资源，由服务器决定新资源的 URL（如自增 id），不幂等（多次创建多个）。
• PUT：用于全量替换指定 URL 的资源，客户端指定完整资源，幂等（多次结果一样）。

选择口诀：创建新资源、id 由服务器生成用 POST；更新/替换已知 URL 的资源用 PUT。 局部改用 PATCH。

五、常见误区

• ❌ 把「安全」理解成「加密安全」——这里指「不改变服务器状态（只读）」。
• ❌ 以为幂等就是「每次返回相同」——是「服务器最终状态相同」，DELETE 二次返回 404 仍幂等。
• ❌ 以为 DELETE 不幂等——删一次和多次最终都是「资源不存在」，幂等。
• ❌ 用 GET 做增删改——GET 应安全幂等，会被预取/缓存，改数据用对应方法。
• ❌ 对非幂等的 POST 直接重试——可能重复下单，要配幂等 token 等设计。

六、常见误区与追问

考点	正确口径
安全	不会修改服务器资源，如 GET/HEAD
幂等	重复执行多次效果相同，如 GET/PUT/DELETE
非幂等	重复执行可能产生新副作用，如 POST

PUT /users/1  same body repeated -> same resource state
POST /orders repeated -> may create multiple orders

安全性看会不会改资源，幂等性看重复执行的最终效果是否一样。

• 误区：安全方法就是网络安全。 这里的安全指不应修改服务器资源，不是指加密或防攻击。
• 误区：DELETE 一定不幂等。 删除同一资源多次，资源最终都是不存在，语义上幂等。
• 误区：POST 永远不能设计成幂等。 POST 通常非幂等，但可通过幂等键、业务去重让特定接口具备幂等效果。
• 追问：PUT 和 PATCH 区别是什么？ PUT 通常整体替换资源，PATCH 表示局部修改，幂等性取决于具体语义。
• 追问：为什么重试要关心幂等？ 网络超时后客户端不确定服务端是否执行，非幂等重试可能产生重复副作用。
• 追问：如何实现支付接口幂等？ 使用业务唯一请求号或幂等键，服务端对重复请求返回同一处理结果。

七、加强记忆

常见方法 GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS。安全性 = 不改服务器状态（GET/HEAD/OPTIONS），幂等性 = 执行一次和多次最终状态相同（GET/HEAD/OPTIONS/PUT/DELETE 幂等，POST 不幂等，PATCH 不保证）。幂等看「最终状态」不看「每次返回」；工程上它决定重试和重复提交是否安全，非幂等的创建/支付要配幂等 token 防重。