服务容器是对象生命周期控制器而非注册表，核心职责为控制创建时机、作用域与依赖解析；默认每次make()新建实例，singleton()实现复用，bind()适合无状态类，singleton()适合有状态或高开销对象。
服务容器不是注册表，是对象生命周期控制器
PHP框架里的服务容器（比如 Laravel 的 Container、Symfony 的 ContainerInterface）常被当成“全局变量收纳盒”，但它的核心职责其实是控制对象的创建时机、作用域和依赖解析链。注册一个类却不指定 singleton 或 scoped，下次 app()->make() 拿到的很可能是新实例——这不是 bug，是设计使然。
- 默认行为多为「每次解析都新建实例」，Laravel 5.5+ 的
bind()就是这样；要复用必须显式调用singleton() - Symfony 容器里
public和private标签影响能否被get()直接访问，不报错但会抛ServiceNotFoundException - 别在
boot()阶段往容器里塞运行时才确定的值（如请求头、用户 ID），该用closure延迟解析，否则容易跨请求污染
Laravel 中 bind() vs singleton() 的实际差异在哪
表面上只是绑定方式不同，但直接影响内存占用和状态一致性。比如你绑定了一个数据库连接管理器：
// ❌ 每次 make() 都 new 一个新对象，连接可能重复建立
app()->bind('DbManager', function () {
return new DbManager(config('database'));
});
// ✅ 全局唯一实例，连接复用，但要注意它内部是否线程安全
app()->singleton('DbManager', function () {
return new DbManager(config('database'));
});
-
bind()适合无状态工具类（如Str、Filesystem），每次拿都是干净的 -
singleton()适合有状态或开销大的对象（DB 连接、缓存客户端），但若类内部用了静态属性或全局资源，得自己保证并发安全 - 别混用：已用
bind()绑定的 key，再用singleton()覆盖，旧绑定不会自动失效，得先unset()或用extend()
如何让容器自动解析带参数的构造函数
容器不是万能的，遇到构造函数含非类型提示参数（比如 __construct(string $prefix, int $timeout)）时，默认会报 UnresolvableDependencyException。必须提前告诉它怎么填。
- 用
bind()+ 闭包手动传参：app()->bind(Service::class, function () { return new Service('api_v2', 3000); }); - Laravel 9+ 支持
contextual binding：对特定类的某依赖指定实现，比如只在PaymentProcessor中注入SandboxHttpClient，而不是全局替换 - 避免在闭包里写复杂逻辑，尤其是涉及 I/O 的（如读配置文件），容器初始化阶段应尽可能轻量；真需要动态值，考虑用
resolve()替代make()触发延迟解析
测试时绕过容器重绑定的坑
单元测试里常用 instance() 或 swap() 替换真实服务，但容易忽略两点：一是容器不会自动清理测试间残留绑定，二是某些框架（如 Lumen）不支持运行时重绑定。
立即学习“PHP免费学习笔记（深入）”；
- PHPUnit 每个 test 方法后建议调用
app()->forgetInstance('SomeService')，否则下一个 test 可能拿到上一个 test 注入的 mock - 别在
setUp()里反复bind()同一个 key，Laravel 默认不覆盖，得先forget()；或者直接用instance()强制替换 - 集成测试中若用
refreshApplication()，整个容器重建，之前的手动绑定全丢——这时要用beforeApplicationDestroyed()或服务提供者重新注册
真正难的不是怎么注册，而是判断某个对象该不该进容器、以什么作用域进、以及谁负责销毁它。这些决定往往藏在一次超时错误或内存泄漏之后才浮现。
