本文介绍如何在 GraphQL 中根据请求参数是否存在，动态选择返回指定地址的账户列表或当前认证用户，利用 @skip 指令与认证逻辑实现灵活、安全的条件分支。
本文介绍如何在 graphql 中根据请求参数是否存在，动态选择返回指定地址的账户列表或当前认证用户，利用 `@skip` 指令与认证逻辑实现灵活、安全的条件分支。
在实际业务中，常需同一接口支持多种语义：例如，当客户端传入 address 时查询对应账户；若未传，则默认返回当前登录用户（即认证上下文中的用户）。GraphQL 原生不支持服务端 if-else 分支，但可通过指令（directive）协同 Schema 设计与解析器逻辑达成目标。
✅ 推荐方案：组合使用 @skip 与 @auth 指令
假设你使用的是 Lighthouse PHP（主流支持 @skip 和 @auth 的 GraphQL 服务框架），可定义如下 Schema：
type Query {
# 当 address 存在且非空时执行 accountByAddress；否则跳过
accountByAddress(
address: String @where(operator: "like")
): [Account!]! @all @skip(if: "address == null || address.trim() == ''")
# 若 accountByAddress 被跳过，则 fallback 到当前认证用户
me: User! @auth
}? 注意：
@skip(if: "...")中的表达式语法依赖具体实现（如 Lighthouse 支持 Twig 风格表达式），需确保address参数可被上下文访问。生产环境建议统一用String（非非空String!）以避免空值校验中断请求。
⚙️ 客户端调用示例
# 场景1：传入 address → 返回匹配账户列表
query GetAccount($address: String) {
accountByAddress(address: $address) {
id
address
}
me @skip(if: $address != null && $address != "") {
id
email
}
}
# 场景2：不传 address → 仅返回 me（自动触发 @auth）
query GetMe {
me {
id
email
accounts @auth(ability: "viewOwnAccounts") {
id
address
}
}
}⚠️ 关键注意事项
-
避免
String!+@skip冲突：String!在参数缺失时会直接报错（GraphQL validation fail），无法进入@skip判断。务必使用可空String类型。 -
@auth不是万能 fallback：@auth仅校验认证状态并注入用户对象，它不会“自动替代”被跳过的字段。真正的条件路由需由客户端协调多个字段，或在服务端封装为单字段联合类型（Union Type）+ 自定义解析器。 -
进阶方案（服务端统一处理）：
若需严格单字段响应，可定义一个泛型字段，例如：userOrAccounts(address: String): UserOrAccountResult! @field(resolver: "Query@resolveUserOrAccounts")
并在解析器中手动判断
address是否存在，再决定返回User对象或[Account]列表（需配合Union或Interface类型）。
✅ 总结
GraphQL 条件查询的核心在于将控制权交还客户端（通过 @skip）、复用认证基础设施（@auth），而非在 Schema 层硬编码分支逻辑。合理设计参数可空性、善用指令组合、辅以客户端协作，即可优雅实现“有参查资源，无参查自身”的常见模式。务必在测试中覆盖空参、空字符串、空白符等边界场景，保障健壮性。
