app() 是完整容器入口，执行绑定、扩展和上下文依赖；resolve() 仅反射实例化，不触发绑定逻辑，故行为不一致。
为什么 app() 和 resolve() 行为不一致？
很多人发现用 app(MyService::class) 能正常拿到实例，但换成 resolve(MyService::class) 却报 Target [MyService] is not instantiable。根本原因在于：resolve() 默认不走容器的自动绑定和扩展逻辑，它只做最简反射实例化，且不触发 bind() 或 singleton() 注册的规则；而 app() 是完整容器入口，会查绑定、执行扩展、处理上下文依赖。
实操建议：
- 统一优先用
app()，尤其在非构造函数注入场景（如控制器方法、命令类 handle 方法） - 仅当明确需要「绕过容器注册逻辑、纯反射构建」时才用
resolve()，比如测试中临时构造无绑定类 - 若坚持用
resolve()加绑定，需手动补全：先app()->bind(MyService::class, MyService::class)，再resolve()
如何让接口绑定生效却避免「循环依赖」警告？
常见错误是这样写：
app()->bind(LoggerInterface::class, function ($app) {
return new FileLogger($app->make(LoggerInterface::class)); // ❌ 自己依赖自己
});
这直接触发 Laravel 的循环依赖检测，抛出 Too many levels of recursion。关键不是“能不能绑”，而是“怎么解耦依赖链”。
正确做法：
- 用
app()->resolving(LoggerInterface::class, ...)延迟到实例化后干预，而非绑定时构造 - 对被依赖方改用具体类名绑定（如
FileLogger::class），接口绑定只留给高层调用方 - 必要时引入中间工厂类，把
$app->make()移到方法内，避开构造时求值
when()->needs()->give() 条件绑定的实际限制有哪些？
这个链式 API 看似灵活，但实际受容器解析顺序严格约束。例如：
app()->when(HttpClient::class)
->needs(LoggerInterface::class)
->give(function ($app) {
return $app->make(FileLogger::class);
});
它只在 HttpClient 构造时被触发，且前提是 LoggerInterface 未被其他绑定覆盖。一旦你之前写了 app()->bind(LoggerInterface::class, ConsoleLogger::class)，这个 when 就完全失效。
使用注意点：
-
when()必须在对应类首次被解析前注册，不能放在服务提供者boot()阶段（太晚），推荐放register() - 不能嵌套条件（如
when(A::class)->needs(B::class)->needs(C::class)不支持） - 闭包里不要调用
$app->make()同一接口，否则可能绕回全局绑定，导致意外交互
服务容器里「单例」和「共享实例」的区别到底在哪？
很多人以为 singleton() 就是“全局唯一”，其实 Laravel 容器里真正决定是否复用的是“是否已解析过该抽象”——singleton() 只是预设了“第一次解析后缓存结果”，但如果你手动调用 app()->forgetInstance()，下次 app() 仍会新建实例。
更隐蔽的问题是“共享上下文”：比如你在队列任务中用 app(MyService::class)，而该服务内部保存了请求 ID，这个 ID 在 Web 请求中有效，但在队列里根本没 Request 实例，就会出错。
所以要盯住两点：
- 用
app()->isShared($abstract)动态检查当前抽象是否已被缓存，比硬记规则更可靠 - 对带状态的服务（如带缓存属性、连接句柄），别盲目
singleton()，优先考虑每次解析都新建，或显式管理生命周期 - 队列、命令行等非 HTTP 场景下，避免依赖
request、session等绑定，它们默认只在 web 中注册
make() 发生在哪个服务提供者阶段、是否已被清空过实例、当前应用环境是否加载了对应绑定。 
