HTTP 协议家族近期新增了 QUERY 方法（RFC 10008），专门用于处理复杂查询场景。
传统方案的局限
用 GET 做查询时，所有条件都塞进 URL 参数里，遇到嵌套结构、多层关联或特殊字符就头疼：参数过长可能触及浏览器或服务器限制，编码后体积膨胀，数组的写法也不统一（?roles=admin&roles=reporter 还是 ?roles[]=admin&roles[]=reporter），而且参数会被服务器日志完整记录。
用 POST 替代虽然能传请求体，但语义就错了——POST 本身定义是「非幂等、用于创建或处理资源」，中间件不会把它当作只读操作，不会自动缓存，也无法安全重试。
QUERY 的设计
QUERY 方法本质上就是「带请求体的 GET」：安全（不产生副作用）、幂等（可重试）、支持缓存（但缓存 key 必须把请求体内容纳入计算）。开发者终于有了一个语义正确的 HTTP 方法来处理复杂查询，无需在语义错误的 POST 和能力受限的 GET 之间妥协。
落地需考虑的现实因素
QUERY 目前支持度仍然有限，Kreya 等工具已在 1.20 版本加入开箱即用支持，但大量代理、防火墙和 Web 服务器可能仍会拒绝该方法。普通 GET 查询若已够用，不必急着改动；如果需要用户分享或收藏带筛选条件的链接，仍应保留 GET。此外，自定义缓存逻辑需要额外把请求体纳入 key 计算，比 GET 更复杂。
总体而言，QUERY 为复杂查询场景提供了语义恰当的解决方案，但在基础设施全面支持之前，建议评估实际需求后再逐步引入。
编注：信源为技术博客 Kreya，文章侧重 RFC 10008 的设计动机与使用注意事项，未涉及具体行业落地案例或企业采纳进度。