这篇文章适合所有后端开发者、API 设计者，特别是面临接口幂等性、资源定位、RESTful 语义设计困惑的人。
“POST 和 PUT 有什么区别”是最常见的面试题之一，但真正落地到项目中，很多人仍容易混用。本文通过真实实践逻辑，帮你彻底理解二者的本质区别和使用边界。
一、定义是基础，但不能只停留在定义层面
HTTP 协议的标准定义如下：
• POST：向指定资源提交数据，通常用于创建资源（非幂等）
• PUT：向指定资源位置上传完整表示，通常用于更新资源（幂等）
但这些定义只是协议层语义。实际应用中，远比这复杂。
二、真正的分水岭：URL 是谁决定的？
关键区别在于：资源的地址是否由客户端确定。
• PUT：客户端指定资源的 URL，意味着“我知道要更新谁”
• POST：客户端向集合发请求，请求服务端创建一个新资源，URL 由服务端分配
示例说明：
• PUT /users/123：更新 ID 为 123 的用户，必须已知该用户的资源路径
• POST /users：在用户集合中新增一个用户，ID 由系统生成
三、幂等性：接口设计的核心考量因素
幂等性指：无论请求执行多少次，结果都一致。
• PUT 是幂等的：多次 PUT 相同内容不会产生副作用
• POST 非幂等：每次调用都可能新增数据或触发副作用
因此，在设计接口时，要考虑是否允许重复调用、是否会新增资源，来决定使用 POST 还是 PUT。
四、常见误用场景拆解
在实际项目中，以下情况经常出现混淆：
• 用 POST 实现更新：虽然能用，但破坏了语义清晰与幂等保障
• 用 PUT 创建资源：如果客户端能指定 URL（如上传文件），这种做法是合理的
• PUT 用于局部更新：不推荐。应该用 PATCH，PUT 更适合整体替换资源内容
五、推荐的 RESTful 接口写法
标准 REST API 设计中，推荐使用如下路径与方法：
• POST /objects：创建资源
• PUT /objects/{id}：整体更新资源
• PATCH /objects/{id}：局部更新
• 避免同时在同一资源上混用 POST 与 PUT
总结：理解语义、掌握幂等性，才能写出健壮 API
POST 和 PUT 的区别不仅仅在于“创建 vs 更新”，而是涉及：
• 资源路径设计
• 请求幂等性保障
• API 语义一致性
真正掌握这几点，才能让你的接口设计在团队协作、系统演进、异常恢复等场景中更稳健、可维护。