绝大多数情况下不该将GraphQL解析器单独拆成Composer包。应优先使用PSR-4命名空间隔离与autoload-dev按需加载，依赖通过DI容器注入而非new实例，并用PHPStan/脚本校验schema与resolver同步。
GraphQL解析器该不该单独拆成Composer包？
绝大多数情况下不该。把 QueryResolver 或 MutationResolver 打包成独立 composer.json 项目，只会让类型绑定变脆弱、调试路径拉长、版本对齐成本飙升——尤其当解析器强依赖当前项目的 Types、DataLoaders 或 Doctrine 实体时。
真正需要拆包的只有两类：可复用的通用能力（如 graphql-php-upload 这类文件上传适配器），或跨多个服务共享的领域 Schema 片段（比如统一的 UserObject 定义 + 对应 resolver 抽象基类）。
- 如果只是按业务域（user、order、product）组织代码，用 PSR-4 自动加载 + 目录隔离就够了
- 若强行拆包，
composer require myorg/graphql-order-resolver会引入不必要的版本约束，导致webonyx/graphql-php主版本升级卡住 - 本地开发时，你得反复
composer update+ 清缓存才能看到解析器改动，而直接写在主项目里改完就能php -S热试
如何在单个 composer.json 里隔离模块依赖？
靠 autoload-dev 和命名空间分组，而不是物理拆包。比如 order 模块用到 mpdf/mpdf 生成 PDF，但 user 模块完全不需要——这时别给整个项目加 mpdf，而是限定 autoload 范围 + 按需 require。
示例：在主项目 composer.json 中
{
"autoload": {
"psr-4": {
"App\Schema\": "src/Schema/",
"App\User\": "src/User/"
}
},
"autoload-dev": {
"psr-4": {
"App\Order\": "src/Order/",
"App\Product\": "src/Product/"
}
},
"require": {
"webonyx/graphql-php": "^14.11",
"laravel/framework": "^10.0"
},
"require-dev": {
"mpdf/mpdf": "^8.2"
}
}
-
require-dev里的包不会进生产环境，但App\Order\下的解析器仍能用 —— 因为它们只在 CLI 命令或测试中触发 PDF 生成 - 如果某个解析器必须在 HTTP 请求中调用 PDF 功能，就把它从
autoload-dev移到autoload，同时把mpdf/mpdf移到require - 别信“按模块 require”的伪方案（比如在
src/Order/composer.json里写依赖）—— Composer 不支持子目录级依赖解析
resolver 类里 new 实例 vs DI 容器注入，哪个更可控？
必须用容器注入。手写 new OrderService() 在 resolver 构造函数里，等于把实例生命周期、配置来源、Mock 替换点全部锁死。
常见翻车点：
- 测试时想 Mock
OrderService，结果 resolver 已经在__construct里 new 出真实实例，根本绕不开 -
OrderService依赖HttpClient，而HttpClient又需要不同环境的不同 base_url —— 手动 new 无法自动切换 - GraphQL 执行器每次请求都新建 resolver 实例，如果构造函数里有耗时初始化（如连接 Redis），QPS 直接掉一半
正确做法：所有 resolver 声明为 service，用容器管理其依赖。Laravel 示例：
// config/graphql.php
'resolvers' => [
'Query.order' => AppOrderResolversOrderQueryResolver::class,
],
对应 resolver 构造函数只接收接口：
class OrderQueryResolver
{
public function __construct(
private OrderRepositoryInterface $repo,
private HttpClientInterface $client
) {}
}
schema.graphql 文件和 resolver 类怎么保持同步不脱节？
靠 PHPStan 或 Psalm 的自定义规则，不是靠文档或人工检查。Webonyx/graphql-php 本身不校验 resolver 方法是否存在或签名是否匹配，运行时报 "Cannot query field "orders" on type "Query"" 或 "Call to undefined method" 才发现，太晚。
- 用
webonyx/graphql-php的SchemaValidator只能查语法，查不出 resolver 缺失 - 推荐加一层静态检查：写个脚本扫描
src/**/*Resolver.php，提取public function resolveXxx()方法名，再对比schema.graphql里所有 field 名称 - CI 流程里跑这个检查，比等 QA 提 bug 快十倍；脚本不用复杂，50 行内搞定，重点是每次
git push就自动触发
最易被忽略的是 nullable 字段的 resolver 返回值类型 —— GraphQL schema 写 orders: [Order!]!，但 PHP 里忘了加 @return array 注解，PHPStan 就没法帮你拦住空数组穿透到非空字段里。
