thinkphp的route::post()不够用，因其默认调用input()触发参数过滤和类型转换，破坏graphql语法；必须用getrawinput()手动解析原始请求体，并按content-type区分处理json或application/graphql格式。
ThinkPHP 实现 GraphQL 接口不能靠默认路由规则或中间件自动解析，必须手动接管 /graphql 路径的原始请求体，并绕过 ThinkPHP 的参数过滤逻辑；否则 variables、operationName 会丢失，query 字符串被二次 decode，直接导致语法错误或静默失败。
为什么 Route::post('graphql', [...]) 不够用
ThinkPHP 的 Route::post() 只控制动词和路径，不改变请求体解析行为。它默认调用 input() 读取参数，而 input('query') 会触发类型转换、trim、htmlspecialchars 过滤——GraphQL 的 query 字符串含花括号、冒号、换行，一过滤就语法失效。
- 错误现象：
Parse error: Unexpected token {或空响应，但 HTTP 状态码是 200 - 根本原因：ThinkPHP 中间件（如
ValidatePostSize、Json）提前 consume 了php://input，后续getRawInput()返回空 - 正确做法：在路由闭包或控制器里第一时间用
$this->request->getRawInput()拿原始 body，且确保该路由跳过所有 JSON 格式校验中间件
如何安全解析 query + variables + operationName
GraphQL 请求体可能是纯 JSON（{"query":"...", "variables":{}}），也可能是 application/graphql 类型的纯字符串（query GetUser { user(id:1) { name } }）。不能只依赖 json_decode()。
- 先判断
Content-Type：若为application/graphql，直接把 raw body 当作query字符串 - 若为
application/json，再json_decode($raw, true)，并检查是否存在query键；不存在则 fallback 到空数组 -
variables和operationName必须从解析后的数组中显式提取，不能省略——否则多 operation 查询会执行错分支 - 示例代码片段：
public function graphql()
{
$raw = $this->request->getRawInput();
$contentType = $this->request->header('content-type');
if (stripos($contentType, 'application/graphql') !== false) {
$input = ['query' => $raw];
} else {
$input = json_decode($raw, true) ?: [];
}
$result = \GraphQL\GraphQL::executeQuery(
$this->getSchema(),
$input['query'] ?? '',
new QueryResolver(),
null,
$input['variables'] ?? [],
$input['operationName'] ?? null
);
return json($result->toArray());
}
Schema 单例化与 resolver 上下文传参
每次请求都重建 Schema 对象会导致 CPU 飙升，尤其在高并发下；resolver 中若直接读 $_GET 或 input()，会绕过上下文隔离，破坏可测试性。
-
Schema必须单例：放在app/common/GraphQLSchema.php，用静态属性缓存，构造时传入已初始化的QueryType和MutationType - resolver 函数签名必须是
function ($root, $args, $context, $info)——漏掉$context，你就拿不到当前 Request 实例或 Auth 用户对象 -
$context应在executeQuery()第四个参数传入，推荐结构：['request' => $this->request, 'user' => $authUser, 'db' => Db::connect()] - 常见坑：
NonNull类型字段 resolver 返回null或0（PHP 中0 == false，但 GraphQL 不认），直接报"Field 'xxx' expected to return 'String!' but got NULL"
调试时别开 ThinkPHP 调试模式
ThinkPHP 的调试模式会捕获异常并渲染 HTML 错误页，而 GraphQL 要求错误必须以 JSON 格式返回到 errors 数组中，否则 Apollo Client、Relay 等客户端会判定为网络失败而非业务错误。
- 上线前务必关闭
app_debug，或在 GraphQL 路由中单独禁用调试中间件 - 执行器要包裹 try/catch，手动构造
['errors' => [['message' => $e->getMessage()]]]，不能让未捕获异常穿透出去 - SDL 文件（
schema.graphql）绝不能放public/目录——会被 ThinkPHP 的deny_files规则拦截返回 403
最易被忽略的是 operationName 的透传和 context 的结构一致性：前端发了多个 operation 却没指定 name，后端 resolver 就可能执行错分支；$context 里塞了 Db 实例却没在每个 resolver 里做连接检测，QPS 上去后容易爆连接池。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
