客户端间调用中用GET请求在Header传数据是否为不良实践？

首先得说，我完全理解你不想大改代码的心态——毕竟重构现有逻辑确实麻烦。但除了违背HTTP语义（GET本应是无副作用、基于URL标识资源的请求），这么做确实还有不少实际的坑，我帮你梳理下：

1. 缓存机制失效，性能下降 #

浏览器、CDN、反向代理这类中间件对GET请求的缓存逻辑，大多是基于URL+少量标准Header（比如Accept-Encoding、Cookie这类）来生成缓存键。如果你把业务参数放到自定义Header里，这些中间件大概率不会把这些Header纳入缓存判断逻辑，导致每次请求都要穿透到源服务器，完全失去了GET请求的缓存优势。如果这个请求调用很频繁，性能损耗会非常明显。

2. 服务器端与中间件的兼容性问题 #

很多服务器框架、WAF、防火墙对GET请求的Header处理有隐性限制：

• 有些反向代理（比如Nginx）默认不会记录自定义Header到访问日志里，以后排查问题时，你根本看不到这些参数的值，调试会变得异常麻烦；
• 部分WAF可能会拦截带有大量自定义Header的GET请求，误认为是恶意攻击；
• 一些老旧的服务器框架对GET请求的Header解析支持不如POST，甚至可能直接忽略非标准Header，导致参数丢失。

3. 维护成本飙升 #

其他开发者接手你的代码时，看到GET请求却在Header里传业务参数，第一反应肯定是困惑——毕竟大家的共识是Header放通用元数据（locale、token、编码信息等），业务参数要么在URL要么在POST Body里。时间久了，很容易出现误操作：比如有人误以为Header里的参数是通用配置，不小心修改或覆盖，导致莫名其妙的bug。

4. 客户端兼容性风险 #

虽然HTTP规范没禁止GET请求带自定义Header，但不少客户端（比如某些旧版本的移动端WebView、第三方HTTP库）对这种场景的支持并不好，可能会直接丢弃自定义Header，导致请求失败。而且如果你的服务要对接第三方客户端，对方的开发团队也会觉得这种做法不符合常规，增加对接成本。

关于性能损耗的补充 #

单纯从报文传输来看，Header里的参数和URL参数的开销其实差不多——都是HTTP请求头的一部分，不会有数量级的性能差异。但前面提到的缓存失效、额外的解析逻辑（服务器要从Header里提取业务参数，而不是直接用框架自带的URL参数解析），这些间接带来的性能损耗才是更值得关注的。

折中建议 #

如果实在不想全量切换到POST，可以先试试这些小优化：

• 压缩参数：把多个参数序列化后用Base64或其他紧凑格式编码，减少长度；
• 移除不必要的参数：检查下是不是有很多冗余参数可以删掉；
• 分批请求：如果参数是批量数据，拆分多个小请求（当然这也要改代码，但改动量可能比全改POST小）。

不过长期来看，还是建议逐步迁移到POST请求——毕竟这才是符合HTTP语义、解决URL长度限制的标准方案，能避免后续更多的隐性问题。

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