GraphQL 在 Symfony 7.2 中需通过 overblog/graphql-bundle 集成，执行 graphql:dump-schema 是前提，失败主因是 PHP 版本不匹配、Doctrine 实体未绑定 Type 或 YAML 配置缺失关键字段；resolver 通过 $context 获取请求与用户信息，Windows 下 ID 必须显式转 string，前端请求须为 JSON 格式且变量须用 variables 字段传递。
GraphQL 在 Symfony 7.2 中不是“开箱即用”的功能，必须靠 overblog/graphql-bundle 集成；不跑通 graphql:dump-schema，后续所有查询都会返回 500 —— 这不是配置问题，是启动校验失败。
执行 graphql:dump-schema 失败的三大高频原因
这个命令是集成的第一道门槛，失败意味着 Schema 构建流程卡在底层依赖环节：
- PHP 版本不匹配：
overblog/graphql-bundle2.x 要求 PHP ≥ 8.2，Symfony 7.2 默认要求 PHP 8.2+，但若系统仍用 8.1，composer require可能静默降级到 Bundle 1.x，导致类型解析崩溃 - Doctrine 实体未绑定 Type：比如
User实体存在，但没写对应的UserType类，或该类没加@Type注解、没在config/packages/overblog_graphql.yaml的types下注册 - YAML 配置缺失关键字段：例如
schema块完全没定义，或definitions下漏了query入口类型（哪怕只是空的QueryType）
resolver 函数里拿不到 $request，但能拿到 $context
Resolver 签名固定为 function ($value, array $args, $context, ResolveInfo $info)，它不接收 HTTP 请求对象。想读 JWT token、当前用户或请求头，必须通过 $context 注入——这是设计使然，不是遗漏。
-
$context的内容由context_provider服务决定，需在config/packages/overblog_graphql.yaml显式配置，例如：context_provider: 'App\GraphQL\ContextProvider' -
ContextProvider类里应注入RequestStack和TokenStorageInterface，把$requestStack->getCurrentRequest()和$tokenStorage->getToken()?->getUser()塞进返回数组 - resolver 内直接用
$context['user']或$context['request']->headers->get('x-trace-id')，干净且可单元测试
Windows 下 ID 字段必须转 string，哪怕数据库是 bigint
Symfony + Overblog + Windows 组合下，GraphQL 的 ID 标量类型对整数敏感：若数据库主键是 bigint，PHP 在 Windows 上可能将其转为 float 后精度丢失，最终 GraphQL 引擎抛出 "Expected value of type \"ID\" but got: 123456789012345.0."
- 解决方案不是改数据库，而是在
UserType的id字段 resolve 里强制转字符串：return (string) $this->id; - 别依赖
@Field(type="ID")自动映射，显式写 resolve 才可控 - 同理适用于所有涉及主键嵌套查询的场景，比如
PostType里关联的user字段返回的User对象，其id也得走同一逻辑
前端 POST 到 /graphdata 时 body 必须是标准 JSON，不能是 form-data
即使你改了路由前缀为 /graphdata，前端 AJAX 仍要严格遵循 GraphQL HTTP 协议：POST、Content-Type: application/json、body 是扁平 JSON 对象，含 query 和可选 variables 字段。
- 错误示例：
fetch('/graphdata', { method: 'POST', body: new URLSearchParams({ query: '{ user(id:"1") { name }' }) })—— 这发的是application/x-www-form-urlencoded，服务端直接 400 - 正确写法：
fetch('/graphdata', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ query: '{ user(id:"1") { name }' }) }) - 变量传参必须用
variables字段，不能拼进 query 字符串里：{ query: 'query GetUser($id: ID!) { user(id: $id) { name } }', variables: { id: "1" } }
最易被忽略的点是 context_provider 的实现细节：它必须返回一个数组，且 key 名会直接透传给所有 resolver；一旦 key 拼错（比如写成 currentUser 但 resolver 里写 $context['user']），就不会报错，只会得到 null —— 这种静默失败最难调试。
