POST的设计则完全不同。它把数据放在请求体里，URL保持干净，且语义上就是“提交、改变、创建”。浏览器不会预取POST，刷新页面时还会弹出“确认重新提交”的提示，因为浏览器知道你这次操作可能有副作用，不能无脑重复。这个差异在表单提交场景下尤其明显：用户填完注册信息点提交，如果用的是POST，网络超时后用户刷新页面，浏览器会询问是否重新发送——这给了用户一个确认机会。如果当初用GET，刷新就直接重复提交了，数据库里可能出现两条一模一样的注册记录。

但别急着下结论说“GET就该只读，POST就该写入”。实际工程里，很多团队把查询参数塞进POST请求体，因为查询条件太复杂，URL长度不够用。比如一个多维度的报表筛选接口，十几个筛选条件拼在URL里，既丑又容易超过某些代理服务器的2KB限制，用POST反而干净。反过来，有些看似“写”的操作，比如点赞、收藏这种高频且可重复的操作，用GET反而能利用浏览器缓存加速——用户反复点同一个链接，服务器可以返回304。这里的关键不是方法名，而是你要搞清楚自己接口的幂等性和缓存需求。

幂等性这个术语听起来吓人，其实就是“重复执行结果是否一致”。GET天然幂等，你请求十次和请求一次，服务器资源没变化。POST不保证幂等，提交两次订单就可能生成两笔交易。但你可以设计成幂等——比如在POST请求体里带一个客户端生成的唯一请求ID，服务器检测到相同ID就返回第一次的结果，不重复创建。这招在支付回调里尤其常用，防止网络抖动导致重复扣款。

还有个经常被忽略的点：GET请求的参数会出现在服务器日志、浏览器历史、代理服务器日志里。你设计的接口如果携带敏感信息，比如token、身份证号，用GET就是裸奔。我见过某公司把用户手机号直接拼在GET的URL里做查询，结果运维查日志时，一堆手机号明文躺在文件里，这要是日志泄露，用户信息全玩完。POST请求体虽然也可能被记录，但至少不会出现在URL和历史记录里，风险面小得多。

最后说个实用判断标准：如果请求是为了获取数据，且不改变服务器状态，用GET；如果请求会导致服务器状态变化，或者参数含敏感信息，用POST。但这不是死规矩。比如登录接口，很多人用POST，因为要传密码。可实际上，登录成功后服务器会种cookie、改session状态，这算“状态变化”，用POST合理。但“查询当前用户信息”的接口，哪怕需要传用户ID，只要ID不是敏感信息，用GET完全没问题，还能享受缓存带来的性能提升。

别把接口设计搞成教条主义。理解每个方法背后的浏览器行为、缓存机制、安全性约束，再结合你的具体场景选。有时候用GET实现“删除”也不是绝对不行——比如删除一个临时生成的、无价值的缓存文件，且这个操作被频繁调用且允许重复执行，GET反而能利用CDN缓存减轻服务器压力。但这种情况太少了，绝大多数场景下，拿不准就选POST，它更安全，也更符合大多数人的直觉。

(责任编辑：知识)