现在 HTTP 请求方法为什么常用的只有 POST 和 GET？
简单来说，是因为绝大多数日常业务场景下，这两个方法就足够表达需求了，其他方法虽然存在，但使用频率低到可以忽略不计（除了某些特定领域）。
下面是目前（2025–2026 年）真实情况的拆解：
1. 使用频率排名（真实项目统计）
| 排名 | 方法 | 实际使用占比（大致） | 典型场景 | 是否常用 |
|---|---|---|---|---|
| 1 | GET | 45–60% | 查询、列表、分页、详情、搜索、下拉选项 | 极常用 |
| 2 | POST | 35–50% | 创建、提交表单、上传文件、登录、支付 | 极常用 |
| 3 | PUT | 2–8% | 整体替换资源（极少用） | 不常见 |
| 4 | PATCH | 1–6% | 部分更新资源 | 少用 |
| 5 | DELETE | 1–5% | 删除资源 | 少用 |
| 6 | OPTIONS | <1%（浏览器自动发） | CORS 预检 | 几乎不手动用 |
| 7 | HEAD | <0.1% | 只取 header，不取 body | 基本不用 |
| 8 | 其他 | ≈0% | CONNECT、TRACE、PURGE 等 | 极少见 |
可以看到：GET + POST 占了 90% 以上，其他方法加起来不到 10%。
2. 为什么其他方法用得少？
| 方法 | 理论语义 | 现实中为什么用得少 | 实际替代方式 |
|---|---|---|---|
| PUT | 整体替换一个资源 | 大部分系统不严格区分“整体替换”和“部分更新”，直接用 POST 更简单 | 用 POST + body 里的操作类型（create/update） |
| PATCH | 部分更新资源 | 实现复杂（JSON Patch / JSON Merge Patch 规范用得少），前端/后端对接成本高 | POST + { op: “update”, data: {…} } |
| DELETE | 删除资源 | 安全问题：很多人不敢让前端直接发 DELETE（怕误删），宁愿用 POST + /delete 接口 | POST /xxx/delete 或 POST + action=delete |
| OPTIONS | CORS 预检 | 浏览器自动发送，前端后端都不需要手动写 | — |
| HEAD | 只取元数据 | 实际场景极少（CDN、缓存校验用得多，但业务代码几乎不用） | — |
一句话总结：
GET 和 POST 几乎可以表达所有业务意图，而且最简单、最不容易出错、最兼容、最好调试，所以大家就都用这两个了。
3. 什么时候还会看到其他方法？
- 严格 RESTful 风格的公司/团队（比较少见）
- 银行、金融、对外开放 API、规范要求高的中大型项目
- 会强制用 PUT/PATCH/DELETE
- GraphQL / tRPC / gRPC 项目
- 基本不依赖 HTTP 方法语义，全靠 POST
- 某些特殊场景
- WebDAV 用 PUT/DELETE/MKCOL 等
- 文件上传/下载用 PUT
- 缓存失效用 PURGE（CDN）
结论（2026 年视角）
在 95% 的业务系统中，GET + POST 就真的够用了。
其他方法更多是“理论上很优雅，实际上很少人愿意为它多写代码、多做约定、多增加复杂度”。
所以现在的真实情况就是：
“能用 GET 就 GET，能用 POST 就 POST，其他的能不写就不写”
—— 这已经成为大多数团队的实际共识。
你现在项目里是全 POST，还是严格按 REST 语义来的？或者前端/后端对 HTTP 方法的使用习惯有什么不同？可以聊聊。
