slim 4 的 container 是带依赖解析能力的关联数组，非自动扫描ioc容器，必须显式注册服务，依赖通过闭包延迟解析实现解耦与单例控制。
Slim 4 的 Container 不是“自动扫描”的 IoC 容器
它本质是个带依赖解析能力的关联数组，不支持类名自动绑定或构造函数参数反射注入（除非你手动配）。很多 PHP 开发者刚从 Laravel 或 Symfony 切过来，会下意识写 $container->get(SomeService::class) 期望自动实例化——结果抛出 NotFoundException。
- 必须显式调用
$container->set()注册服务，哪怕只是匿名函数 - 构造函数依赖不会被自动解析，
function (ContainerInterface $c) { return new Db($c->get('pdo')); }这种写法才是 Slim 的预期用法 - 别把
ContainerInterface当成“万能服务定位器”到处传；它该只在应用启动时（dependencies.php）和中间件/路由回调里用
注册服务时，闭包里用 $container->get() 而不是 new
直接 new UserService($pdo) 看似简单，但会导致测试时无法替换依赖（比如用 mock PDO），也破坏了容器对生命周期的控制。Slim 的容器靠闭包延迟执行来实现单例和依赖解耦。
- 正确写法：
$container->set('user_service', function (ContainerInterface $c) { return new UserService($c->get('pdo')); }); - 如果想复用同一个实例（单例），Slim 默认就是单例行为；若需每次新建，得用
FactoryInterface或手动返回新对象 - 注意闭包参数类型提示必须是
ContainerInterface，否则 Slim 4.10+ 可能因反射失败而报ReflectionException
在路由处理器里获取服务，别在构造函数里硬依赖 ContainerInterface
常见错误是写个控制器类，把 ContainerInterface 塞进构造函数，再在每个方法里 $this->container->get()——这等于把容器当服务定位器滥用，测试时还得 mock 整个容器。
- 推荐做法：路由回调直接接收服务实例，Slim 会自动注入已注册的服务名，例如
function (ServerRequestInterface $req, ResponseInterface $res, array $args, UserService $userSvc) { ... } - 前提是已在容器中注册了
UserService::class对应的工厂，且启用了CallableResolver（Slim 4 默认启用） - 如果服务名和类名不一致（如注册为
'auth' => AuthManager::class），就不能靠类型提示自动注入，得手动$request->getAttribute('route')->getContainer()->get('auth')
测试时替换服务，优先改 Container 而非重写路由
单元测试里最常踩的坑是试图 mock 控制器方法本身，结果绕过依赖注入逻辑，导致测试和运行时行为不一致。
- 真正可控的做法：在测试 setup 阶段重建
Container，覆盖关键服务，比如$container->set('pdo', function () { return $mockPdo; }); - 别在测试里调用
App::addRoutingMiddleware()或其他初始化逻辑——这些属于集成测试范畴；单元测试只管单个处理器或服务的行为 - 注意
Container实例是传递给App构造函数的，所以测试时要确保你测的App实例用的是那个被修改过的容器
容器本身没魔法，它只是帮你把“谁创建谁”这件事从代码里拎出来集中管理。一旦开始在闭包外 new 实例、或者在业务逻辑里反复 get 同一个服务，就等于悄悄退化回了硬编码依赖。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
