Laravel服务容器是核心调度中心，bind()每次请求新建实例，singleton()首次创建后复用；绑定必须在register()中完成，类型提示和命名空间不可省略，make()与resolve()行为不同。
别被“入门教程”四个字骗了——Laravel 服务容器不是学完就能扔的语法糖，而是你写的每一行控制器、中间件、Job 背后都在调用的调度中心。没理解 bind 和 singleton 的区别，上线后数据库连接池爆满、日志上下文串号、测试环境 mock 失效，都是分分钟的事。
bind() 和 singleton() 到底该选哪个
选错就等于给生产环境埋雷。两者注册方式相似，但生命周期和线程安全完全相反：
-
bind()每次app()->make()都新建实例，适合无状态、轻量类，比如JsonResponseBuilder、UrlSigner、DTO 类 -
singleton()首次make()后缓存实例，后续全返回同一对象，适合有状态或高开销资源：数据库连接、Redis 客户端、HTTP 客户端、日志处理器 - 误把
DatabaseConnection用bind()注册 → 每次请求新建连接，几秒内耗尽 MySQL 连接池 - 误把带用户上下文的
RequestContext用singleton()注册 → 多个请求共享同一个$userId，数据串扰
接口绑定必须显式写，不能靠“自动猜”
Laravel 不会自动把 LoggerInterface 映射到 MonologLogger，不绑就报 Target [Psr\Log\LoggerInterface] is not instantiable：
- 绑定必须写在服务提供者的
register()方法里，boot()里写就晚了——此时容器已经开始解析依赖，尤其在队列任务、Artisan 命令中必现失败 - 写法要带完整命名空间：
$this->app->bind(LoggerInterface::class, MonologLogger::class)，不能只写'logger' - 如果实现类构造函数还有依赖（比如
MonologLogger需要HandlerInterface），得确保那个依赖也已绑定或可被反射解析
构造函数注入为什么有时不生效
不是容器坏了，是类型提示或时机没对上：
- 参数必须带类型提示：
__construct(UserRepository $repo)✅，__construct($repo)❌（容器直接跳过） - 标量、数组、默认值参数（如
array $options = []）不会被容器尝试解析，它们得靠闭包绑定或上下文绑定传入 - 手动
new UserController()会绕过容器，所有类型提示都失效——哪怕你写了__construct(CacheManager $cache)，$cache也是null - 报
Target class [xxx] does not exist？先查命名空间拼写、use语句、自动加载是否生效，别急着改绑定逻辑
make() 和 resolve() 别混用
它们行为根本不同，不是同个函数的两个名字：
-
app()->make(MyService::class)是标准入口，走全部绑定规则、单例缓存、扩展逻辑 -
app()->resolve(MyService::class)只做最简反射实例化，不查bind()或singleton()，也不触发上下文绑定——所以常报is not instantiable - 需要运行时传参（比如测试中注入 mock）才用
resolve()：app()->resolve(MyService::class, ['$apiKey' => 'test']) - 生产代码里用
resolve()替代make()绕过单例，说明设计有问题，不是临时方案
最易被忽略的一点：所有绑定必须发生在容器开始解析依赖之前，也就是服务提供者 register() 阶段。任何延迟到 boot()、中间件、甚至控制器里再绑定的操作，都可能在某些场景（队列、命令、并发请求）下静默失效。这不是 bug，是容器的设计前提。
