别把 POST 当万能钥匙：HTML 请求方法的实战抉择

很多开发者写表单或调接口时，遇到提交动作就习惯性套上 POST。结果上线后，搜索页无法通过链接分享，或者网络波动导致订单重复扣款。问题往往不出在代码逻辑，而是对 HTML 请求方法的理解太浅。选对方法，本质上是在维护接口的语义清晰性。

GET 不只是用来查数据的

浏览器地址栏默认就是 GET，但别误以为它能装下所有“读取”操作。GET 必须是幂等且安全的，意味着你按两次刷新键，不应该产生副作用。查看用户列表、搜索商品，用 GET 最合适。它最大的红利是支持浏览器缓存和URL 书签友好，利于 SEO 抓取。

但请记住两个硬伤：一是参数暴露在地址栏，历史记录、代理服务器日志都会泄露数据，密码绝对不能用 GET；二是URL 长度受限，大型复杂表单数据一旦塞进查询参数，可能被服务器截断。

POST 的边界在哪里？

当需要向服务器提交数据且会改变状态时，POST 是最稳妥的选择。注册账号、下单支付、发表评论，这些动作一旦触发就会带来资源增量。这里有个经典坑：缺乏幂等性。如果网络抖动，客户端可能自动重发 POST 请求，后端若未处理防重机制，用户买一份东西就变成了两单。相比之下，GET 的重发通常无害，这就是为什么纯查询逻辑慎用 POST。

PUT 与 PATCH 的更新博弈

到了资源更新环节，新人容易混淆。PUT 代表全量替换。比如改用户资料，传回完整对象，原数据中被遗漏的字段会被强制清空。这在并发场景下风险很大，A 修邮箱，B 修头像，后提交的可能覆盖先提交的。PATCH 才是局部更新，只传递变化的那部分字段。优先推荐 PATCH，既减少带宽浪费，又降低并发冲突概率。

关于 DELETE 的隐忧

DELETE 请求理论上用于删除资源，但线上环境极少允许物理删除。建议将 DELETE 映射为数据库的逻辑删除（标记 deleted_at 字段），保留数据痕迹以便审计恢复。如果直接对接 SQL delete，一旦误操作，数据很难找回。

实际避坑指南

真实场景中，最容易被忽视的是缓存控制。即便使用了 POST，如果服务端响应头没加 Cache-Control: no-store，某些 CDN 仍可能错误缓存响应内容。反之，GET 请求如果是动态计算结果，也必须设置不缓存，避免用户刷出旧数据。

此外，使用 PUT、DELETE 等非简单方法时，浏览器会触发跨域预检（OPTIONS）。这会增加额外的请求延迟，对于实时性要求高的页面，尽量优化接口聚合，减少跨域交互次数。

说到底，方法选择不是为了炫技，而是为了可维护性。给同事看接口文档，对方应该能瞬间明白这个动作是在创建资源还是在检索数据。遵循语义化规范，用正确的动词做正确的事，后期排查性能瓶颈或逻辑 Bug 时，你会感谢现在严谨的自己。别让技术债埋藏在错误的 HTTP 方法里。