为何在REST API的用户数据操作场景下不能仅使用@POST替代@GET？

咱们先从你的实际开发场景出发，拆解下只用@POST为啥会埋下不少隐性问题，而@GET能解决哪些实打实的痛点——这可不是单纯的“REST规范要求”，而是经过大量实践验证的实用准则：

• 缓存带来的性能提升：浏览器、CDN、API网关这类中间件默认会对GET请求做缓存处理。比如你获取用户列表的请求，第一次返回结果后，后续相同请求直接从缓存取，不用再打到后端服务器，不仅响应速度更快，还能大幅降低服务器的负载。但@POST请求几乎不会被缓存，每次都得走完整的后端流程，在用户列表这类高频查询场景下，性能差距会非常明显。

• 语义清晰性与长期可维护性：虽然你现在团队内部都约定好了@POST的用法，但随着项目迭代、新人接手，或者和外部系统对接时，这种“一endpoint多用”的设计会带来理解成本。HTTP方法本身是有语义的：POST代表创建/提交数据，GET代表获取资源，看到@GET("users")任何人都能立刻明白这是拿用户列表，@POST("users")是新增用户，完全不用额外查文档。而混用的话，过几个月你自己看代码都得回忆半天当初的约定。

• 幂等性避免数据风险：GET是幂等的——重复调用多少次，都不会改变服务器上的状态，也不会产生新数据。但POST不是，如果你没在后端做特殊的幂等处理，用户不小心刷新页面、网络波动导致请求重传，都可能重复创建相同的用户，造成数据冗余甚至业务逻辑混乱。比如登录场景下，重复的POST请求可能会给同一个用户创建多条记录，后续排查问题会很头疼。

• 调试与排查问题更便捷：GET请求的参数直接放在URL里，你在浏览器地址栏就能直接测试，日志里也能清晰看到请求的所有参数；而POST的参数在请求体里，测试时得专门构造请求体，排查问题时查看日志也不如GET直观。这种小便利积累起来，能节省不少开发和运维的时间。

• 兼容性更广：有些系统、工具或者旧版客户端对POST的支持不如GET灵活，比如一些监控工具、爬虫，或者某些嵌入式设备的客户端，可能只支持用GET来获取数据。如果你的API只用POST来做查询，可能会遇到意想不到的兼容性问题。

另外，就算现在你的业务只有“新增用户+获取列表”这两个场景，随着业务扩展，比如要加用户分页、按条件筛选（比如按注册时间、角色），用GET的话直接在URL加参数就能实现（比如/users?page=2&role=admin），而用POST的话要么在请求体里塞筛选条件，要么就得修改端点设计，反而会让接口变得越来越臃肿。

说白了，技术上只用@POST确实能实现需求，但@GET带来的这些实际好处，能让你的API更健壮、更易维护、性能更好，这才是真正值得考虑的核心原因。

备注：内容来源于stack exchange，提问作者Rabinarayan Barik