既然PATCH可实现PUT全部功能，为何PUT仍存在？

你提到的情况没错——确实有些场景下发送完整请求体的PATCH能达到和PUT一样的效果，但PUT的存在不是冗余的，核心原因在于HTTP方法的语义约定以及实际开发中的各种场景需求，具体来说有这些关键点：

• 语义明确性是REST的核心
  HTTP方法的价值不在于功能能不能重叠，而在于它传递的语义。PUT的语义是「替换或创建完整资源」，PATCH是「对现有资源做部分更新」。服务器和客户端都会依赖这个语义做逻辑处理：比如服务器收到PUT时，会直接用请求体覆盖整个资源（不管原来的字段是什么）；收到PATCH时，只会修改指定字段。这种明确性能减少沟通成本，其他开发者看到PUT就知道是全量操作，看到PATCH就知道是增量操作，不需要额外猜测逻辑。

• 幂等性的保障程度不同
  虽然PUT和PATCH都被定义为幂等方法，但PUT的幂等性更绝对：多次发送同一个PUT请求，结果100%一致，因为是全量替换。而PATCH的幂等性完全依赖于补丁内容——如果补丁是「把name字段设为张三」，多次执行没问题；但如果补丁是「把count字段加1」，多次执行就会改变结果。在网络不稳定需要重试的场景下，PUT的可靠性更高，客户端可以放心重试，不用考虑副作用。

• 服务器端实现成本更低
  处理PUT的逻辑非常简单：直接接收完整资源，替换掉原有的即可，不需要解析哪些字段要改、哪些要保留。而如果只用PATCH，服务器需要同时处理「部分更新」和「全量替换」两种情况，得判断请求体是完整资源还是增量补丁，这会增加逻辑复杂度和出错概率，尤其是在资源结构复杂的情况下。

• 资源创建场景的适配
  PUT支持客户端指定资源ID的创建场景（比如PUT /users/1001 创建ID为1001的用户），这是REST规范里明确的用法。而PATCH的语义是更新已存在的资源，用它来创建资源不符合通用约定，会让API的行为变得怪异，也容易和现有工具、框架的预期冲突。

• 行业约定的兼容性
  多年来的开发实践已经形成了PUT和PATCH的使用共识，几乎所有API框架、测试工具、客户端库都对这两个方法的语义有默认支持。如果强行只用PATCH，会违反约定，导致其他开发者理解成本上升，也可能和一些自动化工具的逻辑冲突。

内容的提问来源于stack exchange，提问作者Arhit Singal