开发带认证的API时，是否可以用POST请求替代本该使用的GET请求？

结论先行 #

这种做法不符合通用的HTTP API设计规范，不推荐使用，你当前遇到的问题完全有更合理的解决方案，不需要强行修改请求方法。

核心问题梳理 #

你完全不需要为了传userId就把GET改成POST，有两个更规范的实现方式：

• 最推荐：将userId存入token payload中，服务端解密Authorization头的token时直接就能获取到userId，根本不需要前端传递，还能避免前端篡改userId造成越权访问的安全问题。
• 如果不想修改token逻辑：可以把userId放到GET请求的查询参数中，比如请求地址写成 GET /api/user/search-history?userId=xxx，和Authorization头不冲突，完全满足认证需求。

滥用POST替代GET的实际弊端 #

哪怕你觉得当前性能不受影响，长期来看还是会有很多隐性问题：

• 缓存能力缺失：GET请求默认可以被浏览器、CDN、服务端网关缓存，相同请求重复发起时可以直接返回缓存结果，能大幅降低服务器压力和响应耗时，POST请求默认不会被缓存，手动配置缓存的成本也高很多。
• 语义化混乱：HTTP方法的语义是行业通用约定，POST默认代表「会新增/修改服务端资源」，后续维护接口的开发者看到POST请求会默认认为这是写接口，排查问题、对接联调时会增加很多不必要的理解成本。
• 调试、使用成本升高：GET请求可以直接在浏览器地址栏输入调试，浏览器前进后退触发GET请求是无害的，POST请求不但没法直接在地址栏调试，触发前进后退还会提示表单重提交，影响用户体验。

例外情况 #

如果你的查询接口需要传递的参数特别多，超过了浏览器URL长度限制（一般为2KB~8KB），或者参数包含敏感信息不想留存在服务器访问日志中，这种场景下用POST做查询是行业普遍接受的例外处理，你当前的场景不属于这类情况，没必要强行修改请求方法。

内容的提问来源于stack exchange，提问作者camelCaseIsGoodPractice