在现代互联网架构、微服务、网关体系与安全规范下，HTTP 标准方法 PUT / DELETE 正在被大量大厂逐步弃用，转而统一使用 POST + 接口语义 的方案。这不是技术倒退，而是工程化、安全性、兼容性、运维成本综合权衡后的最佳实践。
下面从最核心、最真实的企业级原因讲清楚：
一、网关、防火墙、CDN 不友好（最致命）
绝大多数企业的API 网关、WAF、防火墙、CDN、代理服务器，默认只放行：
- GET
- POST
对 PUT / DELETE 会出现：
- 被拦截、过滤、丢弃
- 缓存策略异常
- 跨域预检（OPTIONS）频繁失败
- 老旧硬件不支持非标准方法
为了兼容全链路，大厂直接选择：全部用 POST，避免不可控风险。
二、跨域场景带来额外性能损耗
浏览器对 非简单请求（PUT/DELETE/PATCH 等）会强制触发：
👉 OPTIONS 预检请求
后果：
- 接口请求量翻倍
- 高并发场景性能下降
- 网关压力增加
- 移动端弱网环境更容易超时
POST 是简单请求，无预检，天然更快、更稳定。
三、安全审计与风控体系不兼容
企业安全团队要求：
- 所有写操作必须记录日志
- 所有风险操作必须鉴权
- 所有请求必须可追踪、可回放
PUT/DELETE 存在问题：
- 请求体支持不统一（有的框架不允许 PUT 带 body）
- 风控系统默认只监控 POST/GET
- 安全策略无法统一拦截危险操作
- 日志系统难以标准化解析
最终安全部门强制要求：统一 POST。
四、微服务 & 网关路由规则难以统一
微服务架构中：
- GET：查询
- POST：新增/操作
- PUT：全量更新
- DELETE：删除
- PATCH：部分更新
方法太多 → 网关配置复杂、路由规则混乱。
大厂统一规范：
只用 GET（查）+ POST（操作/写/改/删）
删除、修改、上传、异步任务全部用 POST。
路由规则极简，维护成本暴跌。
五、框架兼容性差，容易踩坑
不同语言、框架对 PUT/DELETE 支持不一致：
- 某些老版本框架 PUT 不支持请求体
- 某些网关 丢弃 DELETE 的 body
- 某些序列化库 无法解析 PUT 参数
- 爬虫/测试工具 对非标准方法支持弱
统一 POST = 全平台兼容，零坑。
六、可观测性、监控、告警更简单
运维、SRE 团队喜欢统一方法：
- 统计写请求：只看 POST
- 统计查询：只看 GET
- 告警规则：只配置两种方法
- 链路追踪：格式统一
如果混入 PUT/DELETE，监控面板会变得复杂且容易出错。
七、企业级接口规范：删除/更新不代表“危险动作”
RESTful 认为：
- DELETE = 删除资源
- PUT = 覆盖资源
但真实业务中：
- 删除大多是 逻辑删除（is_deleted=1）
- 更新大多是 部分更新
- 上传是 POST + 文件
- 批量删除是 POST 批量操作
动作语义 > HTTP 方法语义
所以企业直接用：
POST /api/user/delete
POST /api/user/update
POST /api/user/batch-delete
清晰、安全、无歧义。
八、最真实的大厂现状
你现在接触的 阿里、腾讯、字节、美团、京东、拼多多、快手 等：
✅ 90% 后端接口只使用 GET + POST
✅ PUT/DELETE 基本只存在于内部基础设施
✅ 对外 API、网关、前端调用一律禁用
✅ 安全规范明确禁止非 GET/POST 方法
最终总结（一句话记住）
PUT/DELETE 被弃用，不是因为它们不对，而是因为工程化、兼容性、安全性、运维成本太高。统一使用 GET + POST，是企业级架构最稳定、成本最低、风险最小的方案。
