Shopify 把 GraphQL 执行从深度优先改成广度优先：瓶颈不在 I/O，在字段解析器

GraphQL 的常规执行模型是深度优先：解析一个字段，递归解析它的子字段，完成之后再回到兄弟字段。这个模型直观、容易理解，在大多数应用里工作得很好。但 Shopify 在 2026 年 3 月公开的迁移记录给出了一个不同的结论：在高基数查询模式下，深度优先执行本身就是一个扩展瓶颈，而且瓶颈不在 I/O，在运行字段解析器本身的时间。

深度优先的隐藏成本来自解析器的调度方式。当一个查询包含大量嵌套字段和高基数集合时，深度优先遍历会逐个解析字段，很多解析器在等待 I/O 时被挂起，但解析器的调用、上下文切换、结果组装本身的 CPU 开销并不会因为 I/O 等待而消失。Shopify 的追踪显示，大部分请求时间并不一定花在执行 I/O 上，而是经常花在运行构建 GraphQL 响应的字段解析器上。也就是说，在深度优先模型下，解析器调度的开销本身成了限制吞吐的因素。

广度优先执行改变的是解析器的调度顺序：先解析同一层的所有字段，再进入下一层。这个模型让同一层的解析器可以更集中地调度，减少了深度优先递归带来的逐字段切换成本；在高基数模式下，同一层的字段数量很大，广度优先的批处理效应更明显。Shopify 把这个新执行引擎称为 Cardinal，并描述了把一个庞大的生产 GraphQL 栈迁移到全新执行模型所需要的工作。

这个案例的工程含义不是“广度优先一定比深度优先好”。对于大多数中小规模的 GraphQL 查询，深度优先的差异可以忽略，迁移成本不值得。但当一个 GraphQL API 的查询模式变成高基数、深层嵌套、大量同层字段时，执行模型的调度开销会从“背景噪音”变成“主要成本”。这时候优化数据加载器、加缓存、换数据库，可能都不是第一杠杆；换执行模型的调度方式，才是。

对正在运营 GraphQL 服务的团队来说，一个可操作的观察是：如果你的追踪显示请求时间大量花在解析器执行而不是下游 I/O 上，而且查询模式有高基数特征，执行模型值得进入排查清单。Shopify 的迁移不是一次“换个库”的升级，是重写执行引擎；普通团队不需要走到那一步，但理解“深度优先的递归调度本身有成本”这件事，可以帮助你在性能归因时不再只盯着数据库和网络。GraphQL 的性能问题不总是“N+1 查询”或“缓存没命中”，有时候是执行模型和查询形状之间的错配。