技能介绍

你在生产里真正会撞上的墙

GraphQL 把「客户端要什么字段」交还给前端，代价是服务端要扛住任意形状的查询。N+1 会让每个列表项在解析器里各打一发数据库请求；深度嵌套查询可以在几分钟内把 CPU 和连接池吃光；可空性设计不当时，非空字段一失败会把整条父对象抹成 null，客户端分不清是「没权限」还是「真没数据」。

这套技能在帮你做什么

技能以曾大规模落地 GraphQL API 的视角组织内容，覆盖从 schema 到客户端的整条链路：

Schema 设计：类型安全的 schema，可空性按业务语义设计，而不是「全 nullable 省事」。
解析器与 DataLoader：用批量加载与缓存打断 N+1，而不是每个 resolver 各自 findById。
联邦与订阅：graphql-federation、subscriptions 的常见模式与运维注意点。
工具链：graphql-codegen、Apollo Server / Client、urql，以及基于 type policies 的规范化客户端缓存。

文档里同时列出明确反模式（不用 DataLoader、不限制查询深度、只在 schema 层做鉴权），并用表格对照「严重程度 → 解法」，例如生产环境禁用自省、解析器与字段级鉴权、查询复杂度/成本限制、订阅生命周期清理。

适用边界

它面向后端与全栈工程师做 API 设计与排障，不是 GraphQL 语法入门课。与 backend、postgres-wizard、nextjs-app-router、react-patterns 等技能叠用时，更容易把「查询形状」和「数据层批量访问」对齐。若团队尚未接受「必须限制深度/复杂度」这类运维约束，先谈架构共识再套模式，否则客户端仍可能用合法查询拖垮服务。

截图预览

使用场景

列表 GraphQL 接口在压测或高峰时数据库 QPS 异常升高，需要在本请求内用 DataLoader 批量合并解析器查询。
客户端可构造深度嵌套查询，上线前要在 Gateway 或 Apollo Server 上配置查询深度、复杂度与成本限制。
产品要求区分「无权限」与「字段无数据」，需要重梳 schema 可空性，并在解析器层做字段级鉴权与错误语义。
多个团队各自维护 subgraph，需要按联邦模式聚合 schema，并统一在 resolver 而非仅 directive 中校验访问权限。

适合人员

维护 B 端 GraphQL 列表与关联查询、在代码评审里反复被点名 N+1 与批量加载的后端工程师。
在 Next.js App Router 中集成 Apollo Client，需要按 type policies 设计规范化缓存、避免列表与详情不一致的全栈开发。
负责 Apollo Federation 或自建 GraphQL 网关，要在 subgraph 边界与字段级统一鉴权策略的平台或基础架构同学。
经历过生产自省暴露 schema 或昂贵查询拖垮实例，需要补查询限制与 resolver 鉴权的 API 或 SRE 负责人。