CodeIgniter原生不支持GraphQL，需集成webonyx/graphql-php手动实现；其MVC架构与GraphQL单端点、查询驱动等特性天然不匹配，接入时需绕过CI封装、自定义解析器、显式定义schema与resolver，并排除CSRF拦截。
CodeIgniter 原生不支持 GraphQL，直接“使用 GraphQL”需要自己接入第三方库并手动搭建执行层——这不是配置开关，而是补全缺失的协议栈。
为什么 CodeIgniter 没有内置 GraphQL 支持
CodeIgniter 是传统 MVC 框架，路由、控制器、视图都围绕 RESTful HTTP 方法（GET/POST）和固定 URL 路径设计。GraphQL 的核心特征——单端点 /graphql、请求体带查询字符串、字段按需返回、类型系统驱动——与 CI 的请求分发机制天然不匹配。
你不会在 system/ 里找到 GraphQL_parser 或 GraphQL_controller，官方也从未将 GraphQL 列为路线图目标。
用 webonyx/graphql-php 实现最小可行接入
最轻量且维护良好的方案是集成 webonyx/graphql-php（PHP 官方推荐实现），绕过框架封装，直接在控制器中处理 GraphQL 请求。
- 通过 Composer 安装：
composer require webonyx/graphql-php - 新建控制器（如
App\Controllers\Graphql），在index()中读取php://input，解析 JSON 请求体 - 手动构造
GraphQL\Server\StandardServer或更简单的GraphQL\GraphQL::executeQuery()，传入 schema 和查询 - 注意：不要复用 CI 的
$this->input->post()——GraphQL 查询通常走 POST body，但不是表单编码，而是 raw JSON - 示例关键片段：
$rawInput = file_get_contents('php://input'); $input = json_decode($rawInput, true); $result = GraphQL::executeQuery($schema, $input['query'], $rootValue, $context, $input['variables'] ?? null);
Schema 定义必须脱离 CI 模型直连数据库
GraphQL 的 schema 描述的是「能力边界」，不是「数据来源」。你不能把 $this->User_model->get() 直接塞进 resolver；必须显式定义 type、field、args，并在 resolver 函数里调用模型——否则字段权限、懒加载、N+1 等问题立刻暴露。
- resolver 示例中，
UserType的posts字段应返回new Promise(...)或用defer延迟加载，而非同步查库 - 避免在 resolver 里写
$this->db->where(...)->get()——CI 的 DB 类实例未在 GraphQL 执行上下文中自动注入，需手动传递或重构为服务类 - 类型定义建议放在
App\GraphQL\Types\下，用 PHP 类而非数组，便于 IDE 跳转和类型提示
调试时最常见的三个硬坑
GraphQL 错误不报在浏览器控制台，也不进 CI 日志——它静默失败或返回 200 + 错误 JSON，极易误判。
-
"debug": true必须显式传给executeQuery()，否则堆栈被吞掉，只剩"Internal server error" - schema 中 resolver 返回
null但字段非 nullable？会触发"Cannot return null for non-nullable field"——检查每个resolve函数末尾是否真有 return - CI 的 CSRF 验证默认拦截所有 POST 请求，
app/Config/Filters.php中要排除graphql路由，否则 403
真正难的不是写 schema 或 resolver，而是让 GraphQL 的「请求即文档」「字段即契约」思维，和 CI 的「URL 即动作」「控制器即胶水」习惯共存——每次加一个新字段，都要重新校准数据流、错误传播和缓存策略。
