GraphQL.NET 中片段引用与执行策略的深度解析

引言

在 GraphQL.NET 项目中，GetRecursivelyReferencedFragments 方法的行为引发了一个值得深入探讨的技术问题。该方法当前返回所有递归引用的片段，包括那些由于 @skip 或 @include 指令而被跳过的片段。本文将详细分析这一设计决策的影响、潜在解决方案以及相关技术考量。

核心问题分析

在 GraphQL 查询执行过程中，片段（Fragment）的使用是一个重要特性。然而，当这些片段被 @skip 或 @include 指令修饰时，它们可能不会在实际执行中被包含。当前实现中，GetRecursivelyReferencedFragments 方法返回所有片段引用，无论它们是否会被执行。

这种设计在某些验证规则（如内置验证）中是合理的，但对于其他场景（如权限验证）则可能产生问题。权限验证需要准确知道哪些片段会被执行，以便正确应用权限检查。

技术影响

1. 权限验证场景：在权限验证中，如果包含被跳过的片段，可能导致不必要的权限检查，甚至错误地拒绝合法查询。

2. 性能考量：重复计算片段引用关系会带来额外的性能开销，特别是在复杂查询中。

3. 代码一致性：目前权限验证需要自行实现片段引用收集逻辑，与核心功能存在重复代码。

解决方案探讨

改进方案

主要建议是修改 GetRecursivelyReferencedFragments 方法，增加一个布尔参数来控制是否包含被跳过的片段。这提供了灵活性：

• 设为 true：保持现有行为，适用于大多数内置验证规则
• 设为 false：仅返回实际执行的片段，适用于权限验证等场景

实现挑战

1. 执行上下文依赖：判断片段是否被跳过需要访问执行策略和变量值，这在验证阶段尚不可用。

2. 执行阶段依赖：ShouldIncludeNode 方法目前依赖 ExecutionContext，而该上下文在验证阶段尚未构建。

3. 验证阶段限制：变量值的解析发生在验证之后，限制了在验证阶段准确判断片段是否被跳过的能力。

替代方案评估

1. 方法迁移：将 ShouldIncludeNode 移至 Schema 类，减少依赖，但会丧失部分灵活性。

2. 代码复制：在方法内部复制跳过逻辑，作为临时解决方案，但会导致代码重复。

3. 分阶段处理：仅在验证第二阶段（变量解析后）提供精确的片段引用信息。

最佳实践建议

1. 分阶段处理：对于需要精确片段信息的验证规则，建议安排在验证的第二阶段执行。

2. 自定义覆盖：当需要特殊跳过逻辑时，可以通过覆盖 ShouldIncludeNode 和 SkipNode 方法实现。

3. 性能优化：对于复杂查询，考虑缓存片段引用计算结果以避免重复工作。

结论

GraphQL.NET 中片段引用的处理是一个需要平衡多种需求的设计问题。当前实现提供了基础功能，但在精确控制方面存在改进空间。通过引入参数化控制和分阶段处理策略，可以在保持向后兼容的同时，为高级用例提供更好的支持。这一改进将特别有利于权限验证、复杂度分析等需要精确执行信息的高级功能。