app\services 是服务容器的使用者而非容器本身，其类由容器创建和注入；真正配置容器行为的是 app/config/services.php，需在此显式定义静态方法或闭包来注册服务，并优先通过构造函数类型提示实现依赖注入。
App\Services 是服务容器的“使用者”，不是容器本身
CodeIgniter 4 的服务容器（ServiceContainer）是一个底层对象，负责自动解析依赖、实例化类、管理单例生命周期。而 App\Services（通常指 app/Services/ 目录下的自定义服务类）只是被容器创建和注入的普通类——它既不管理容器，也不参与依赖解析逻辑。
常见误解是把 App\Services\UserService 当作“服务提供者”，其实它只是业务逻辑载体；真正注册、配置、绑定行为发生在 app/Config/Services.php 中。
Services.php 才是服务容器的“配置入口”
app/Config/Services.php 是唯一能直接影响容器行为的地方。它通过静态方法向容器注册服务，例如：
public static function userService()
{
return new \App\Services\UserService(
service('database'),
config('App')->userCacheTTL ?? 300
);
}
这个方法不会被自动调用，只有当代码中执行 service('userService') 时，容器才会触发该静态方法并缓存返回值（默认为单例）。
关键点：
-
service()函数本质是\Config\Services::getContainer()->get()的快捷封装 - 所有自定义服务必须在这里显式定义静态方法，否则容器无法识别
- 若未定义同名方法，
service('xxx')会尝试按类名自动解析，但仅限无标量参数的类
构造函数里用 service() 不等于“注入”，而是手动获取
在控制器或服务类的构造函数中直接调用 service('logger') 属于“服务定位器（Service Locator）”模式，绕过了依赖注入机制：
class UserService
{
public function __construct()
{
$this->logger = service('logger'); // ❌ 隐式依赖，难测试
}
}
正确做法是让容器自动注入：
class UserService
{
public function __construct(\CodeIgniter\Log\LoggerInterface $logger)
{
$this->logger = $logger; // ✅ 类型提示触发自动解析
}
}
这样做的好处：
- 单元测试时可轻松传入 Mock 对象
- 依赖关系显式声明，不隐藏在方法体内
- 避免因
service()调用时机不当导致的初始化顺序问题
闭包绑定才是处理标量参数的正解
当你的 App\Services\FileLogger 构造函数需要字符串路径或整数级别等非类参数时，Services.php 必须用闭包显式控制实例化过程：
$container->set('FileLogger', function ($container) {
return new \App\Services\FileLogger(
config('App')->logLevel ?? 'info',
WRITEPATH . 'logs/app.log'
);
});
这里容易踩的坑：
- 闭包参数
$container可用于获取其他已注册服务（如$container->get('database')） - 不要在闭包里调用
service()，它可能引发循环依赖 - 闭包内硬编码配置值会降低环境适配性，应优先从
config('App')或env()读取
复杂点在于：一旦用了闭包，你就放弃了自动装配能力，必须手动拼凑所有参数——包括那些本可由容器自动提供的类依赖。
