GraphQL服务端需三大核心组件：多源数据执行引擎、可复用类型定义机制、自动映射多源到统一Schema的中间层；关键在延迟加载与按需委托，配合Promise/Deferred调度、DataLoader去重合并、代码优先Schema构建及错误隔离与缓存。
GraphQL服务端需要什么核心组件？
纯靠写 graphql-php 原生解析器撑不住复杂聚合场景。你真正需要的是三样东西：一个能处理多源数据的执行引擎、一套可复用的类型定义机制、以及能自动把不同数据源（MySQL、REST API、Elasticsearch）映射到统一 Schema 的中间层。Composer 不是魔法，它只是帮你把 webony/graphql-federation、graphql-php 和 league/flysystem 这类轮子按需拼起来。
怎么让不同数据源在同一个 Query 里共存？
关键不是“接入”，而是“延迟加载 + 按需委托”。比如一个 user 字段要从 MySQL 查，而它的 posts 关联字段要调第三方 REST 接口，不能等 user 返回后再发 HTTP 请求——那样会串行阻塞。正确做法是用 Promise 或 Deferred 包装每个 resolver，再由 GraphQL\Executor\Executor::promiseToExecute() 统一调度。
- MySQL 数据用
doctrine/dbal封装成 lazy-loading repository，resolver 中只返回new Deferred(fn() => $repo->find($id)) - REST 接口用
guzzlehttp/guzzle配合AsyncClient，resolver 返回Promise实例，别直接->send() - 避免在 resolver 里做
foreach循环调多个 ID——改用 DataLoader，用overblog/dataloader-php提供的DataLoader类批量去重+合并请求
Schema 定义容易踩哪些坑？
很多人用 GraphQL\Utils\SchemaPrinter::doPrint() 导出 SDL 后手动维护，结果 resolver 和类型对不上。更稳的方式是用代码优先（code-first）：用 webony/graphql-schema-builder 或手写 GraphQL\Type\Definition\ObjectType 实例，在 PHP 层统一生成 Schema，而不是靠字符串拼接或 YAML 转换。
- 字段名和数据库列名不一致？别在 resolver 里硬映射，用
resolve回调参数里的$value和$info动态判断上下文 - 嵌套层级深导致 N+1？检查是否漏了
FieldResolver的resolve方法返回的是 Promise/Deferred，而不是直接返回数组 - Union 类型报
Abstract type must resolve to an object？确保每个 concrete type 的isTypeOf回调返回布尔值，且不能依赖未加载的关联数据
聚合层上线前必须验证的两件事
一是查询计划是否真的并行——加日志看 MySQL 查询和 HTTP 请求的起止时间戳是否重叠；二是错误传播是否干净——当 Elasticsearch 超时，不能让整个 GraphQL 响应崩掉，得靠 try/catch 包住每个数据源调用，并返回 userError 而非 internalServerError。
立即学习“PHP免费学习笔记（深入）”；
- 用
graphql-php的ValidationRule自定义规则，拦截maxDepth超限或字段数爆炸的恶意查询 - 聚合层没有缓存逻辑？至少给每个 resolver 加
cacheKey，配合symfony/cache存 Redis，但注意：带变量的查询（如user(id: $id)）必须把变量值参与 key 计算 - 别忽略
extensions字段——把实际耗时、SQL 执行数、HTTP 调用数打进去，否则出问题时连哪一层拖慢都定位不了
