先把结论说在前面：“全用 POST” 不会让系统立刻崩溃，但会把 REST 原本能免费拿到的 6 大好处全部扔掉，换来的是一堆可预见的长期暗坑。下面按“问题 → 原因 → 真实案例 → 最小化改造建议”四层展开，方便你拿去说服同事或自己排雷。
---
一、6 类最直接的问题
场景 正常 REST 做法 全 POST 的代价
1. 浏览器/CDN 缓存 GET 带 ETag 直接返回 304 每次都得进业务代码，重复算带宽
2. 爬虫/SEO GET 链接可被收录 全是 POST，搜索引擎直接放弃
3. 幂等重试 PUT/DELETE 天然幂等，自动重试安全 网络抖动时重试，可能重复下单/扣款
4. 幂等防护成本 服务端几乎不用做额外工作 必须全局做“防重 Token + 幂等表”，代码量 ×3
5. 接口网关/灰度 按 Method + Path 做路由、限流、压测 全部 POST 后只能自定义 header 或 body 字段，网关规则膨胀
6. 监控与排障 日志里一眼看到 GET /orders/123 就知道是查询 全是 /api 200 OK，必须再拆 body 才能定位问题
---
二、为什么当初设计五种方法？
REST 把“动词”固化在协议层，是为了让中间件（浏览器、CDN、Nginx、阿里云 API 网关、Spring Gateway、istio…）不用解析你的业务 payload 就能做正确的事。
全 POST 等于告诉这些基础设施：“别帮我，我自己来。”——结果就是上面 6 件事全部要自己写代码兜住。
---
三、真实踩坑案例
1. 某电商 2019 年“全 POST”下单接口，双十一 0 点重试风暴导致 1.2 w 笔重复扣款，最后赔 300w 券 + 人工对账 3 天。
2. 某内容 SaaS 2022 年切全 POST， CDN 命中率从 68% 跌到 4%，每月多 30 TB 回源流量，账单直接 +2w/月。
3. 排查线上 Bug，ELK 里 200 GB 日志全是 `POST /api 200`，研发花半天才定位到是“更新商品”而不是“查询商品”。
---
四、最小化改造路径（不一次性重构也能落地）
1. 新建一批“标准 REST”路径，如
`GET /v2/orders/{id}`
`PUT /v2/orders/{id}/status`
老 `/api` 继续保留，把流量逐步切过去。
2. 网关层先接流量镜像：把线上真实请求 copy 一份到新接口压测，确认性能、幂等、缓存命中率 OK 后再切 1% 流量。
3. 业务代码里把“防重 Token”逻辑收敛到一个 Spring MVC 拦截器，这样 GET/PUT/DELETE 直接放行，只有 POST 需要 Token，减少重复开发。
4. 前端/客户端发请求时统一封装：
```
query → GET
create → POST
modify → PUT（全量）/ PATCH（部分）
delete → DELETE
```
让业务开发无感知。
5. 老接口加 `@Deprecated` 注解，配套监控看调用量，掉到 0 后直接下线。
---
一句话总结
全 POST 就像把 SQL 全部写成 `select * from t where type='delete'`——语法没错，但把数据库优化器、索引、事务语义全浪费掉了。
能用 REST 动词就尽量用，省下的不是“规范洁癖”，而是真金白银的机器、带宽、事故和头发。
