为什么大厂逐渐弃用 PUT、DELETE 请求？

在现代互联网架构、微服务、网关体系与安全规范下，HTTP 标准方法 PUT / DELETE 正在被大量大厂逐步弃用，转而统一使用 POST + 接口语义 的方案。这不是技术倒退，而是工程化、安全性、兼容性、运维成本综合权衡后的最佳实践。

下面从最核心、最真实的企业级原因讲清楚：

一、网关、防火墙、CDN 不友好（最致命）

绝大多数企业的API 网关、WAF、防火墙、CDN、代理服务器，默认只放行：

• GET
• POST

对 PUT / DELETE 会出现：

1. 被拦截、过滤、丢弃
2. 缓存策略异常
3. 跨域预检（OPTIONS）频繁失败
4. 老旧硬件不支持非标准方法

为了兼容全链路，大厂直接选择：全部用 POST，避免不可控风险。

二、跨域场景带来额外性能损耗

浏览器对 非简单请求（PUT/DELETE/PATCH 等）会强制触发：
👉 OPTIONS 预检请求

后果：

• 接口请求量翻倍
• 高并发场景性能下降
• 网关压力增加
• 移动端弱网环境更容易超时

POST 是简单请求，无预检，天然更快、更稳定。

三、安全审计与风控体系不兼容

企业安全团队要求：

• 所有写操作必须记录日志
• 所有风险操作必须鉴权
• 所有请求必须可追踪、可回放

PUT/DELETE 存在问题：

1. 请求体支持不统一（有的框架不允许 PUT 带 body）
2. 风控系统默认只监控 POST/GET
3. 安全策略无法统一拦截危险操作
4. 日志系统难以标准化解析

最终安全部门强制要求：统一 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，是企业级架构最稳定、成本最低、风险最小的方案。