HTTP 方法语义不应只按“参数放 URL 还是请求体”记忆。安全方法表示客户端不要求、也不期望该请求改变服务器状态；幂等方法表示相同请求重复执行多次，其预期效果与执行一次相同。幂等不要求每次响应完全相同，也不禁止服务器记录访问日志等副作用。

方法	常见语义	安全	幂等
GET	获取表示	是	是
HEAD	获取响应头	是	是
POST	按资源处理提交内容，常用于创建/动作	否	通常否
PUT	用请求表示创建或替换目标资源	否	是
PATCH	对资源做局部修改	否	不保证，取决于补丁语义
DELETE	删除目标资源	否	是

这些是协议语义，不保证每个应用都实现正确。例如 GET 不应被设计成“点击即扣款”；爬虫、预取和缓存可能自动发起 GET。PUT 重试通常应写入同一目标状态；POST 创建资源若每次生成新记录则不幂等，但可用业务幂等键实现重复提交防护。DELETE 第二次可能返回 404，但目标已删除这一预期效果仍可视为幂等。

浏览器通常对 GET 响应缓存，但是否可缓存还要看状态码和缓存头；POST 也不能简单说绝对不可缓存。方法语义和缓存规则应分别讨论。

重试策略应结合方法语义与业务键设计：网络超时只能说明客户端没及时收到响应，不能证明服务端没有执行。对于创建订单或支付等请求，可由客户端带唯一请求标识，服务端持久化处理结果并对同一标识去重。还要定义幂等键作用范围、有效期和参数冲突行为，避免把重复请求误当作不同业务。

常见追问#

安全方法等于没有任何副作用吗？#

不是。服务器可能写访问日志或统计数据；“安全”描述客户端请求的预期语义是不要求改变目标资源状态，不代表实现绝对零副作用。

幂等和安全有什么关系？#

安全方法通常也是幂等的，但反过来不成立。PUT、DELETE 通常幂等，却会改变资源状态，因此不是安全方法。

POST 能做幂等吗？#

可以通过服务端幂等键、请求去重或业务唯一约束实现重复提交保护，但这属于应用设计，不改变 POST 方法通常非幂等的通用语义。

PATCH 一定非幂等吗？#

不一定。把字段设置成固定值的补丁可以幂等；“余额增加 10”这种增量操作重复执行则不幂等，须看具体补丁语义。