服务容器本质是带缓存的回调注册表：记录绑定、解析依赖（基于反射和类型提示）、缓存实例（仅singleton），无魔法，核心是bind/singleton差异与依赖解析逻辑。
服务容器本质是啥？不是“魔法”，就是个带缓存的回调注册表
很多人被 App::make() 或 resolve() 的自动实例化吓住，以为容器在“猜”你要什么。其实它只做三件事：记录绑定（bind / singleton）、解析依赖（递归调用构造函数参数类型提示）、缓存实例（仅限 singleton）。没有反射就无法工作，但反射只是工具，不是原理核心。
关键点：
-
bind('foo', fn() => new Foo())：每次解析都执行闭包，返回新实例 -
singleton('foo', fn() => new Foo())：首次解析后把实例存进$instances数组，后续直接返回 - 若没显式绑定，容器会尝试用反射读取类构造函数的类型提示，然后递归解析那些依赖——这就是“自动注入”的全部逻辑
bind 和 singleton 绑定后，解析行为差异在哪？看源码级表现
差异不在注册时，而在 build() 和 get() 的调用路径上。真正决定是否复用的是 isShared() 判断和 $instances 缓存检查。
app()->bind('logger', function ($app) {
return new \Monolog\Logger('web');
});
app()->singleton('cache', function ($app) {
return new \Illuminate\Cache\Repository(
$app->make(\Illuminate\Cache\StoreInterface::class)
);
});
上面两行之后：
- 每次
app()->make('logger')都新建一个Logger实例 - 首次
app()->make('cache')构造并缓存；第二次起直接从$instances['cache']返回同一对象 - 如果对同一个抽象反复调用
bind()，后一次会覆盖前一次的$bindings条目；但singleton()不会覆盖已缓存的实例
类型提示解析失败的常见原因：不是容器坏了，是 PHP 或配置没对齐
报错 Target [SomeInterface] is not instantiable 是最典型信号，说明容器找不到该接口的具体实现绑定，或实现类构造函数有未满足的依赖。
排查顺序：
- 确认是否漏了
$this->app->bind(SomeInterface::class, SomeImplementation::class)或在AppServiceProvider@register()里写了等效代码 - 检查
SomeImplementation的构造函数参数：所有类型提示类是否也都可被容器解析？比如含new DateTime()这种硬编码就必然失败 - 留意命名空间拼写，特别是
use语句漏了\导致解析成当前命名空间下的类 - 若用了 PHP 8.0+ 的构造函数属性提升（
public function __construct(private UserService $service)），容器仍能反射到，但 IDE 可能误报未定义
何时该用 bind，何时必须 singleton？别凭感觉，看对象生命周期
选型依据只有一个：这个对象是否允许被多次实例化？
- 数据库连接、缓存仓库、事件分发器——必须
singleton，否则每次请求建一堆连接或重复初始化 - DTO、Request、FormRequest、临时计算类——适合
bind或不绑定（让容器自动反射），因为它们本就不该跨请求共享状态 - 注意陷阱：
singleton绑定闭包时，闭包内$app->make()拿到的仍是最新容器状态；但闭包外提前$app->make()并赋值给变量再传入，则可能捕获旧实例
复杂点在于“部分共享”：比如一个类依赖一个单例 + 一个每次新建的策略对象。这时不能整个类设为 singleton，而应在构造函数里明确接收单例依赖，并让容器自动注入非共享依赖——容器本身不管理对象内部组合逻辑，只管按需提供。
