好问题！用自定义HTTP Header（比如你提到的X-Full-Info）来控制业务逻辑，确实是个容易踩的隐性坑，咱们一步步拆解为什么这种做法不推荐，以及为什么Query Parameter是更优的选择：

1. 违背HTTP Headers的设计初衷 #

HTTP Headers的核心作用是传递请求/响应的元数据——比如认证信息（Authorization）、内容类型（Content-Type）、缓存策略（Cache-Control）这类和业务逻辑无关的辅助信息。把X-Full-Info这种业务开关塞进Headers里，相当于把业务逻辑硬塞进了元数据层，不符合HTTP规范的设计意图，会让API的语义变得模糊，后续维护的开发者需要额外花费精力理解这种“非常规”的控制方式。

2. 缓存与CDN的兼容性灾难 #

绝大多数缓存系统（包括浏览器缓存、CDN、反向代理）默认是**基于URL（含Query Parameter）**生成缓存键的，但不会把自定义Headers纳入缓存判断逻辑。这会导致：

• 用户A用X-Full-Info: true请求到了详细内容，缓存系统把它存在了对应URL下；
• 用户B不带这个Header请求同一个URL，却拿到了缓存的详细内容，而非默认的简单信息；
  反过来也可能出现需要详细内容时却拿到了缓存的简单结果，这类问题非常难排查，会直接破坏缓存的有效性。而Query Parameter（比如?full_info=true）会被包含在缓存键中，缓存系统能精准区分不同请求场景，避免这类问题。

3. 调试与协作成本高 #

用Query Parameter的话，你可以直接把完整URL（比如https://api.example.com/data?full_info=true）复制给同事，或者在浏览器地址栏里快速修改参数测试。但用自定义Header的话，每次调试都得在Postman、Chrome DevTools这类工具里手动添加Header，没法通过URL直接传递请求逻辑。而且很多日志系统只会记录URL，不会完整记录所有自定义Headers，出现问题时很难追踪请求的具体参数。

4. API文档与可发现性差 #

主流的API文档工具（比如Swagger/OpenAPI）对Query Parameter的支持非常成熟，能自动生成参数说明、示例请求，开发者一眼就能看到这个开关的存在。但自定义Headers往往需要额外的文字说明，很容易被忽略，增加了开发者的学习成本，也不符合API设计的“自解释”原则。

5. 前端跨域的额外性能开销 #

如果你的API要被前端页面调用，用自定义Headers发起跨域请求时，浏览器会自动发送一次OPTIONS预检请求，确认服务器是否允许这个自定义Header，这会多一次网络往返，影响请求性能。而Query Parameter不会触发预检流程，跨域请求更顺畅。

当然，这不是说所有自定义Headers都不好——比如Authorization这类符合HTTP规范的头是完全没问题的，但用来控制业务逻辑（比如返回不同内容粒度）就偏离了Headers的定位。改用Query Parameter的话，既符合HTTP设计规范，又能解决上面提到的所有痛点，是更稳妥的选择。

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