PUT用于全量替换资源，必须提交完整数据；PATCH用于局部更新，仅传输变更字段，但需服务端明确支持对应补丁格式。
PATCH 请求和 PUT 请求到底该用哪个
别一上来就选 PATCH——它不是“更轻量的 PUT”，而是语义完全不同的操作。PUT 要求你提供完整资源表示，服务器会用整个 payload 替换目标资源；PATCH 只传变更部分，但服务器必须能理解这个“补丁”怎么应用。很多后端没实现标准 Patch 逻辑，而是把 PATCH 当成“不校验完整性的 PUT”来处理，结果导致字段被意外清空（比如漏传 email，数据库里就变 null）。
- 确认 API 文档是否明确支持
PATCH，并说明了补丁格式（JSON Patch、JSON Merge Patch 还是自定义） - 如果文档只写了“支持 PUT/PATCH”，默认按 JSON Merge Patch 行为测试：未出现的字段保留原值，出现的字段覆盖
- 生产环境首次用
PATCH前，先用GET拿原始数据，再比对响应体，验证字段是否真的只改了想改的那几个
Postman 里怎么填对 PATCH 的 Body 和 Headers
填错 Content-Type 是最常见失败原因。Postman 不会自动帮你设对，必须手动点进 Headers 标签页加一行：
-
Content-Type: application/json—— 绝大多数 REST API 用这个，哪怕只改一个字段 -
Content-Type: application/json-patch+json—— 如果 API 明确要求 JSON Patch（比如要带op、path、value字段），否则会直接返回415 Unsupported Media Type - 删掉 Postman 自动加的
Content-Length—— 它有时算错长度，导致请求卡住或 400 - 如果需要鉴权，
Authorization头必须和GET或PUT一致，不能因为“只是部分更新”就漏掉
Body 选 raw，语言下拉选 JSON，然后只写你要改的字段，例如：
{"status": "archived", "updated_by": "admin"}
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
为什么发了 PATCH 却没生效，或者报 405 Method Not Allowed
405 错误不是你配错了，是服务端根本没开 PATCH 路由。很多框架（比如 Express、Spring Boot 默认配置）压根不注册 PATCH 方法，只认 PUT 和 POST。
- 先用
OPTIONS请求试探：在 Postman 里选OPTIONS方法，发到同一个 URL，看响应头Access-Control-Allow-Methods里有没有PATCH - 检查 URL 是否带尾部斜杠 ——
/users/123/和/users/123在某些路由配置下会被当成不同端点，后者可能没注册PATCH - 如果确定服务端不支持，别硬刚，改用
PUT+ 完整资源数据（先GET再改再PUT），这是最稳的 fallback 方案
批量更新多个资源时别用单个 PATCH 请求硬扛
想一次改 100 个用户的 role 字段？别在 Postman 里手写 100 个 PATCH 请求——效率低、难调试、还容易触发限流。
- 优先查 API 是否提供批量接口，比如
POST /users/bulk-update，这种才是设计用来干这事的 - 如果只有单条
PATCH端点，用 Postman 的 Collection Runner + CSV 数据文件，让 Postman 自动跑 100 次，URL 和 Body 用变量替换（如{{user_id}}） - 注意并发数别设太高（Runner 里默认 1），Elasticsearch 或 MySQL 直连后端可能瞬间被打满，建议从 3 开始试
真正容易被忽略的是：PATCH 的幂等性不保真。两次相同 PATCH 请求，可能第一次成功、第二次因数据已变而失败（比如状态机不允许重复归档）。这点比 PUT 严苛得多，测试时得专门设计“重复提交”场景。
