一句话筛选标准：
「整资源覆盖、且客户端拥有完整最新表示」 的修改，用 PUT；其余一律 PATCH/POST。
---
满足 3 个条件即可放心 PUT
1. 你知道资源全量字段（包括服务器可能生成的隐藏字段也要回传或允许空）。
2. 重复调用结果完全一致（幂等）。
3. 不会触发额外业务副作用，或副作用也是幂等可接受的（如更新时间戳）。
---
常见「适合 PUT」的正例
场景 请求示例 为什么合适
替换商品详情 PUT /products/123 带上全部字段 字段少、客户端有全量数据
更新文章草稿 PUT /drafts/456 标题+正文全量覆盖 富文本编辑器本地保存完整内容
修改个人昵称+头像 PUT /profile/789 同时传新昵称、新头像 URL 字段固定、全量替换
覆盖上传文件元数据 PUT /files/abc 文件名、权限、标签全写 文件系统语义就是整体覆盖
重置配置模板 PUT /configs/app 把整个 JSON 配置一次性写回 配置中心常见做法
---
常见「别用 PUT」的反例
场景 原因
修改密码 需要旧密码校验、盐值、加密策略，客户端拿不到完整表示
订单发货 会触发库存、物流、消息，非幂等资源覆盖
退款、提现、转账 产生新流水，不是“替换”而是“创建逆向单据”
点赞/收藏/关注 通常是增量计数或关系插入，用 POST/PATCH
部分更新用户资料（只改手机号） 客户端没传全量字段，用 PATCH
---
速记口诀
“手上有整图，敢覆盖，用 PUT；只改一角，或不知道后台还有啥，用 PATCH/POST。”
)
