在 RESTful 架构大行其道的今天，标准的 HTTP 方法（GET、POST、PUT、DELETE）分工明确，被视为 API 设计的“黄金法则”。然而，在实际的工程落地中，尤其是中小团队或外包项目中，你经常会遇到一种“反直觉”的规定：“别管什么增删改查，所有接口统一用 POST。”
这种做法常被技术大佬诟病为“不规范”、“RESTful 洁癖的噩梦”。但在特定的开发环境和业务场景下，这却是一种极具性价比的“防御性编程”策略。为什么会有这种规定？这究竟是偷懒还是为了生存？
一、核心原因：规避“参数传递”的深坑
在 HTTP 协议中，GET 和 POST 的参数传递方式有着本质区别，这也是导致统一使用 POST 的最直接技术动因。
URL 长度限制的噩梦
GET 请求：参数必须拼接在 URL 后面。虽然 HTTP 协议本身没有限制 URL 长度，但浏览器和服务器都有实际限制。例如，IE 浏览器限制 2083 个字符，Nginx 默认限制 4k-8k，Tomcat 默认限制 8k。
场景痛点：当你的查询条件非常复杂（例如：批量 ID 查询、复杂的筛选组合、Base64 编码的图片数据），URL 极易超长，导致 414 URI Too Large 错误。
POST 优势：POST 请求将参数放在 Request Body（请求体）中，理论上没有长度限制（仅受服务器配置限制，通常可达数 MB）。统一用 POST，彻底杜绝了“参数太多传不过去”的问题。
特殊字符转义的麻烦
GET 请求：URL 中不能包含某些特殊字符（如空格、&、=、中文等），必须进行 URL Encode 编码。如果前端忘记编码，或者后端解码逻辑不一致，就会出现乱码或参数截断。
POST 优势：POST 通常配合 application/json 格式使用，JSON 对字符串的处理非常友好，不需要繁琐的转义，大大降低了前后端联调时的沟通成本。
二、安全与缓存：隐式的安全感
虽然 HTTPS 普及后，GET 和 POST 在传输层都是加密的，但在应用层和中间件层面，POST 依然具有独特的“安全感”。
避免敏感信息泄露
GET 请求：参数暴露在 URL 中。这意味着它们会被记录在浏览器历史记录、服务器访问日志（Access Log）、代理服务器日志中。如果 URL 里包含密码、Token 或身份证号，这就是巨大的安全隐患。
POST 优势：参数在 Body 里，不会出现在 URL 日志中，天然适合传输敏感数据。
防止意外的缓存命中
GET 请求：浏览器和 CDN 节点默认会缓存 GET 请求。如果你的接口是“获取用户余额”或“获取验证码”，一旦缓存策略配置不当，用户可能会看到旧数据，或者因为缓存导致验证码无法刷新。
POST 优势：浏览器默认不缓存 POST 请求。对于逻辑复杂、实时性要求高的接口，统一用 POST 可以避免处理复杂的 Cache-Control 头，减少“数据不更新”的诡异 Bug。
三、团队协作与运维层面的“降本增效”
除了技术细节，统一使用 POST 往往更多是出于管理成本的考量，特别是在以下两类团队中最为常见：
人员流动大、水平参差不齐的团队
如果团队成员对 RESTful 理解不深，很容易出现滥用 GET 做修改操作（例如用 GET 请求去删除数据），这不仅不安全，还容易被爬虫误伤。
制定“全员 POST”的规则，相当于把复杂度降维。新人入职不需要培训 RESTful 规范，只要知道“发 JSON 包”这一种模式即可，极大地降低了培训和纠错成本。
网关与鉴权系统的简化
很多公司的 API 网关或 WAF（Web 应用防火墙）在处理签名校验时，解析 Body 比解析 URL 参数更统一。
统一使用 POST + JSON，可以让网关层的代码逻辑极其简单：只需要解析 Body 即可，无需分别处理 Query String 和 Body 两种参数源。
四、最佳实践科普：GET vs POST vs PUT vs DELETE
虽然“全员 POST”有其合理性，但作为开发者，我们仍需了解标准方法的定义，以便在更规范的场景中做出正确选择。
GET（获取）
定义：从服务器检索数据。
特点：幂等（多次请求结果一致）、安全（不修改数据）、可缓存。
适用：搜索商品、获取文章详情、拉取列表。
POST（创建/提交）
定义：向指定资源提交数据进行处理（通常用于创建新资源）。
特点：非幂等（多次请求可能创建多个资源）、不可缓存。
适用：用户注册、提交订单、上传文件、复杂查询。
PUT（更新/替换）
定义：更新现有资源，如果资源不存在则可能创建。
特点：幂等（更新多次结果一样）。
适用：修改用户信息、更新文章状态。
DELETE（删除）
定义：删除指定资源。
特点：幂等。
适用：删除订单、取消关注。
结语
规定“所有接口都用 POST”，本质上是在“理论完美”与“工程落地”之间做出的妥协。
如果你的团队是大厂精英，追求极致的 RESTful 规范和 HATEOAS 架构，那么请严格遵守标准。
但如果你的团队处于创业期、外包项目交付期，或者内部系统对接频繁且参数复杂，那么“全员 POST”绝对是一个能帮你少掉头发、少出 Bug、快速上线的明智之举。
技术是为了业务服务的，能解决问题的规范，就是好规范。
