Yii容器是服务定位器与轻量IOC混合体，按需实例化且不强制注册依赖；Laravel容器强制契约驱动，支持上下文绑定、闭包绑定及清晰解析链错误提示，并以app()为唯一入口杜绝组件直访。
Yii 和 Laravel 都用服务容器实现依赖注入，但底层逻辑、绑定方式和实际使用手感差别不小——不是“换个写法就行”，而是“改个配置可能就失效”。
Yii 的 Yii::$container 是服务定位器 + 轻量 IOC 混合体
它默认行为更像一个可配置的工厂：调用 get() 时才实例化，不强制构造函数参数必须提前注册。但这也带来隐性风险：
- 没显式
set()或setSingleton()的类，每次get()都新建实例（包括带依赖的类），容易误以为是单例 -
Yii::$container->set('logger', ['class' => 'app\components\FileLogger'])这种数组配置写法，对 IDE 友好度低，重构时难追踪 - 接口绑定需手动写
Yii::$container->set(LoggerInterface::class, FileLogger::class)，且不支持上下文绑定（比如“只在命令行请求中用 ConsoleLogger”）
Laravel 的 app()->bind() 强制契约驱动，但灵活性藏在细节里
它要求你明确声明抽象（interface 或 class）和具体实现的关系，不写绑定就报错，反而减少了运行时不确定性：
-
app()->bind(LoggerInterface::class, FileLogger::class)后，任何地方 type-hintLoggerInterface都能自动注入，控制器、中间件、任务类都生效 - 用
app()->singleton()才真正复用实例；bind()默认每次解析都新建——这点和 Yii 的set()行为相反，容易踩坑 - 支持闭包绑定：
app()->bind(Connection::class, function ($app) { return new Connection($app['config']['db']); });，适合需要运行时计算依赖的场景
依赖注入失败时，错误信息暴露程度完全不同
Yii 报错常卡在 ReflectionException: Class xxx does not exist，尤其当类名拼错或命名空间漏 autoload 时，不提示是容器哪一步出问题；Laravel 则会在 Target [xxx] is not instantiable 后附上完整解析链，比如 “resolving Controller → resolving Service → resolving Repository”，方便逆向排查。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
更隐蔽的问题是：Yii 允许构造函数参数类型为 array 或 string 这类标量，容器直接传 null 或空数组过去不报错；Laravel 默认拒绝标量类型注入，必须用 with() 显式传参，强迫你把配置项和业务逻辑解耦。
真实项目里最容易被忽略的一点
Yii 的容器和应用实例（Yii::$app）长期共存，很多老项目习惯直接 Yii::$app->myComponent 访问组件，绕过容器——这会让单元测试难 mock，也掩盖了真正的依赖关系；Laravel 的容器是唯一入口，app() 就是容器本身，没有“应用实例”这一层抽象，从设计上就杜绝了这种混用。
