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"}
为什么发了 PATCH 却没生效，或者报 405 Method Not Allowed
405 错误不是你配错了，是服务端根本没开 PATCH 路由。很多框架（比如 Express、Spring Boot 默认配置）压根不注册 PATCH 方法，只认 PUT 和 POST。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 先用
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 严苛得多，测试时得专门设计“重复提交”场景。
