Laravel服务容器是应用启动与运行的底层引擎，必须在初始化阶段正确注册绑定；它全程驱动生命周期，绑定须在服务提供者register()中显式声明，bind()与singleton()需按资源特性严格区分，类型提示和命名空间必须完整准确。
Laravel服务容器不是部署环节的“附加配置”，而是整个应用启动、运行、响应请求的底层引擎。它不依赖外部环境部署动作，但必须在应用初始化阶段正确注册与绑定——理解这点，才能避开90%的线上依赖失效、单例错乱、测试mock失败问题。
服务容器不是“装东西的盒子”，而是调度中枢
它全程参与Laravel生命周期：从index.php加载bootstrap/app.php开始，到服务提供者register()注入绑定，再到路由分发时自动解析控制器参数，最后到队列任务反序列化执行——每一步都由容器驱动。所谓“部署”，本质是确保config/app.php中列出的服务提供者全部加载，且它们的register()方法被执行。
- 没在
register()里绑定？make()直接报Target [X] is not instantiable - 在
boot()里绑定？部分场景（如Artisan命令、队列Job）已错过解析时机，依赖为null - 用
app()->bind()在中间件或控制器里临时绑定？该绑定只对当前请求有效，且无法被反射机制识别，类型提示失效
bind() 和 singleton() 必须按资源特性选，不能凭感觉
选错等于给生产环境埋雷：
-
bind()：每次
app()->make()都新建实例。适合无状态、轻量、可随意复制的对象，比如UrlSigner、JsonResponseBuilder、DTO类 -
singleton()：首次
make()后缓存并复用同一实例。适合有状态或高开销资源，例如PDO连接、RedisClient、带上下文的日志处理器 - 误用
bind()注册数据库连接 → 短时间内耗尽MySQL最大连接数 - 误用
singleton()注册RequestContext（含当前用户ID）→ 多个并发请求共享同一个$userId，数据串号
接口绑定必须显式声明，没有“自动猜”这回事
Laravel不会自动把Psr\Log\LoggerInterface映射到Monolog\Logger，哪怕它们命名空间看起来“合理”。所有接口绑定必须写死在服务提供者的register()中：
- 写法必须带完整命名空间：
$this->app->bind(LoggerInterface::class, Logger::class) - 不能简写成
$this->app->bind('logger', ...)，否则类型提示无法匹配 - 若实现类构造函数还有依赖（如
Logger需要HandlerInterface），该依赖也得提前绑定或能被反射自动解析 - 别指望
composer dump-autoload能修复绑定错误——先检查命名空间拼写、use语句、是否漏掉ServiceProvider注册
依赖注入生效的前提，比你想象的更严格
不是写了__construct(UserRepository $repo)就一定注入成功：
- 参数必须带完整类型提示，
__construct($repo)会被容器完全忽略 - 标量、数组、带默认值的参数（如
array $options = []）不参与自动解析，需用闭包绑定或上下文绑定传入 - 手动
new UserController()会彻底绕过容器，所有类型提示形同虚设 - 路由闭包、控制器方法、事件监听器支持自动注入；但模型观察者、自定义验证规则类等，需确认是否通过容器解析（多数需手动
app()->make()）
make() 与 resolve() 不是同义词，混用必出问题
它们行为完全不同：
-
app()->make(MyService::class)是标准入口，走全部绑定规则、单例缓存、扩展逻辑 -
app()->resolve(MyService::class)跳过绑定缓存和扩展，强制重新反射构造函数并实例化，适合调试或特殊场景 - 在队列任务中用
resolve()可能重复初始化连接池；在单元测试中用make()才能命中mock绑定
