服务容器本质是带依赖解析能力的注册表，维护binding与resolved instances数组；make()查缓存并递归解析类型提示依赖，bind()每次新建实例，singleton()仅首次构造并缓存；自动注入失败多因类未加载、标量参数或命名参数不支持；resolve()跳过回调与缓存，仅注入依赖。
服务容器本质是个带依赖解析能力的注册表
它不是魔法，而是一个维护 binding（绑定）与 resolved instances（已解析实例）的数组结构。每次调用 app()->make(SomeClass::class)，容器会先查缓存，没命中就按绑定规则构造实例——关键在于「如何构造」：若类有构造函数参数，容器会递归解析每个类型提示的依赖。
bind() 和 singleton() 的底层差异在 resolved 实例存储时机
bind() 每次调用 make() 都新建实例；singleton() 在第一次 make() 时执行构造并把结果存进 $instances 数组，后续直接返回该引用。注意：即使你用 bind() 绑定一个闭包，只要闭包里返回的是新对象，它仍是“每次新建”——容器不干涉闭包内部逻辑。
app()->bind('logger', function ($app) {
return new FileLogger('/var/log/app.log'); // 每次 make 都 new 一次
});
app()->singleton('cache', function ($app) {
return new RedisCache($app['redis']); // 只第一次执行，结果被缓存
});
自动注入失败通常卡在类型提示无法解析
常见报错如 Target class [SomeService] does not exist 或 Unresolvable dependency resolving [Parameter #0 [ 。原因包括：
-
SomeService类文件未被自动加载（Composer autoload 未覆盖路径） - 构造函数参数是标量（
string、int）或接口无对应 binding - 用了 PHP 8.0+ 的命名参数但容器版本不支持（Laravel 9+ 才完整支持）
- 依赖链中某环节抛出异常，导致递归解析中断
调试可用 app()->resolving(function ($object, $app) { var_dump(get_class($object)); }); 查看哪些类被成功解析。
resolve() 和 make() 的行为区别影响测试和重构
make() 走完整生命周期（包括 resolving / resolved 回调）；resolve() 仅做依赖注入，跳过回调和单例缓存检查。这意味着：
- 单元测试中用
resolve()可绕过某些副作用（比如日志记录、数据库连接初始化） - 手动 new 对象再传给
resolve()时，容器不会管理其生命周期，也不会触发retrieving事件 -
resolve()不接受字符串别名，只接受具体类名或对象实例
$service = new MyService(); // 手动创建 app()->resolve($service); // 仅注入依赖，不走 binding 规则Laravel 容器的复杂点不在绑定语法，而在「何时触发解析」「谁负责释放资源」「循环依赖检测边界」——这些细节在写自定义 ServiceProvider 或替换默认容器实现时才会真正暴露。
