服务容器自动解析类名失败表现为“no service for type x”错误、构造函数参数为null或调用时出现“call to a member function on null”；根本原因是ci4容器仅解析已注册服务或能通过反射推断完整类名的类型提示，不扫描代码库、不猜测别名/接口实现/无命名空间类；解决需确保psr-4路径与命名空间一致、接口手动绑定、标量参数用工厂注册、运行时数据改用方法传参，并勿遗漏父类构造函数调用。
服务容器自动解析类名失败的典型表现
运行时抛出 No service for type X 错误，或构造函数参数为 null，控制器/过滤器启动即报错；更隐蔽的情况是——类被实例化了，但依赖项没注入，后续调用方法时才触发 Call to a member function on null。
为什么自动解析会“找不到类”
CI4 的服务容器只对**已注册的服务**或**能通过反射推断出完整类名的类型提示**做自动解析。它不扫描整个代码库，也不猜测别名、接口实现或未声明命名空间的类。
- 类没在容器中显式绑定（比如自定义的
UserRepository接口没映射到具体实现） - 构造函数参数用了接口类型，但容器里没配置该接口的实现绑定
- 类文件存在但命名空间与文件路径不一致（如
App\Repositories\UserRepository却放在app/Models/下） - 使用了 PHP 8.0+ 的联合类型（
string|int）或可空类型（?Logger），容器无法确定该注入哪个具体类
怎么让服务容器正确解析你的类
核心原则：让容器“知道你要什么，且知道去哪里找”。不是靠猜，是靠声明。
- 确保类有正确的命名空间和
use语句，且文件路径与 PSR-4 规则严格匹配（如App\Repositories\UserRepository必须在app/Repositories/UserRepository.php） - 若依赖接口，必须在
app/Config/Services.php的public static function initialize()中手动绑定：$container->singleton('App\Repositories\UserRepositoryInterface', 'App\Repositories\DatabaseUserRepository'); - 对需要标量参数（如字符串、整数）的类，不能依赖自动解析，必须用闭包或工厂方式注册：
$container->singleton('App\Logging\FileLogger', function ($container) { return new \App\Logging\FileLogger('debug', WRITEPATH . 'logs/app.log'); }); - 避免在构造函数中混用可自动解析的类和服务容器无法处理的标量参数——CI4 不支持混合自动/手动注入
构造函数里传参失败，千万别这样写
常见错误是把运行时数据（比如 $userId、$token）塞进控制器或服务的构造函数：
-
public function __construct($userId)→ CI4 会直接报错，因为容器无法提供这个值 -
public function __construct(UserModel $model, string $mode)→$mode没法自动解析，整个构造函数注入失败 - 正确做法：运行时数据一律通过方法参数传入，构造函数只接收容器能管理的服务对象
最易被忽略的一点：父类构造函数调用不是可选项。控制器里漏掉 parent::__construct()，会导致 $this->request、$this->session 全是 null，看起来像“注入失败”，实际是生命周期没走完。
