PHP不支持GraphQL Federation开箱即用，因缺乏联邦网关实现，子服务需手动实现_entities字段并统一@key解析，网关层须用Node.js或Rust构建；务实方案是PHP网关用curl_multi_exec并发聚合子服务响应。
GraphQL Federation 在 PHP 中不是开箱即用的方案，官方 webonyx/graphql-php 库本身不支持联邦网关（federated gateway）能力。PHP 微服务做图聚合，得自己搭“联邦层”，不能直接照搬 Apollo 的 @key、@external 那套。
为什么 PHP 项目难直接接入 GraphQL Federation
联邦协议依赖两个关键机制：服务注册时上报 __service SDL、网关运行时按需向子服务发起 _entities 查询。PHP 生态缺乏成熟的联邦网关实现——graphql-php 是执行器，不是网关；lighthouse-php 支持部分联邦语法但仅限于子服务端（即作为被聚合方），不提供网关调度逻辑。
常见错误现象：Cannot query field "_entities" on type "Query"，本质是 PHP 子服务没暴露 _entities 入口，或网关根本没把查询分发过去。
- 所有子服务必须手动实现
_entities字段解析器，并注册到自己的 Schema 中 - 必须统一约定服务标识字段（如
@key(fields: "id")对应的 resolver 要能从representations数组里提取id并查库 - 网关层得用 Node.js（Apollo Gateway）或 Rust（Ultratrace）等语言实现，PHP 做不了联邦协调者
PHP 微服务做图聚合的务实替代方案
与其硬啃联邦规范，不如用 PHP 擅长的方式做“类联邦”聚合：在 API 网关层用 curl_multi_exec 并发调用多个 GraphQL 子服务，再手工拼装响应。这比强推联邦更可控、更易调试。
- 每个子服务仍用
webonyx/graphql-php提供标准/graphql端点，但不启用联邦指令 - 网关服务写一个统一入口（如
/federated），接收客户端查询 AST 或字段路径白名单 - 根据查询中涉及的类型（如
User、Order）路由到对应子服务，构造最小化子查询（避免全量{ user { id name } order { id total } }） - 用
curl_multi_exec并发请求，超时设为CURLOPT_TIMEOUT_MS = 800，失败则返回空对象或降级值，不阻塞整体响应
字段映射与错误处理的关键细节
子服务返回结构不一致是常态：用户服务返回 {"data": {"user": {...}}}，订单服务可能返回 {"data": {"order": {...}}}，甚至带 "errors" 字段。PHP 网关必须在 curl_multi_info_read 完成后，逐个检查：
立即学习“PHP免费学习笔记（深入）”；
- 用
curl_getinfo($ch, CURLINFO_HTTP_CODE)拿真实状态码，非 2xx 直接跳过该段数据 - 用
json_decode(curl_multi_getcontent($ch), true)解析，再判断json_last_error() === JSON_ERROR_NONE - 字段提取走白名单映射（如
['user' => 'data.user', 'order' => 'data.order']），别用isset($res['data']['user'])这类脆弱判断 - 对空响应或超大响应（>3MB）提前截断并记录告警，防止 OOM
