Laravel依赖注入依靠服务容器自动解析构造函数类型提示，但必须在服务提供者register()中正确绑定接口或类，用bind()（每次新建）或singleton()（单例复用）匹配生命周期，否则引发连接耗尽、状态错乱或解析失败。
直接说结论：Laravel 的依赖注入不是靠手动 new 或全局变量，而是靠服务容器自动解析类型提示——只要你把接口或类名写在构造函数参数里，容器就能按绑定规则给你塞进去；但前提是绑定得对、时机得准、方式得当。
bind() 和 singleton() 用错会导致内存泄漏或状态错乱
普通 bind() 每次调用 app()->make() 都新建实例，适合无状态、轻量对象（比如 DTO、策略类）；singleton() 只创建一次并复用，适合数据库连接、缓存客户端、HTTP 客户端等有状态或开销大的服务。
- 误用
bind()绑定DB或Cache实例 → 每次请求都新建连接，快速耗尽数据库连接池 - 该用
singleton()却写了bind()→ 缓存失效、事务隔离异常、日志上下文丢失 -
instance()必须传入已初始化的实例，不能传未设置好依赖的对象（比如new SmsService()但env()还没加载完）→ 后续make()返回的对象会抛出Undefined index: twilio_sid类错误
接口绑定必须放在 register()，boot() 里写就晚了
服务提供者的 register() 方法是容器注册阶段，所有绑定必须在此完成；boot() 是“启动后”阶段，此时容器已经开始解析依赖，再绑定可能被跳过，尤其在队列、命令或测试环境下极不稳定。
- 检查
config/app.php的providers数组是否包含你的服务提供者类（默认有AppServiceProvider::class，但自定义 provider 容易漏加） - 别在
boot()里写$this->app->bind(...)，哪怕它看起来能跑通——这是时序陷阱，CI 环境下大概率失败 - 接口绑定要写全命名空间：
App\Contracts\SmsServiceContract::class，不能只写字符串'sms'，否则类型提示无法匹配
make() 和 resolve() 参数行为完全不同
make() 只认服务名（字符串或类名），走标准解析流程；resolve() 允许你传入参数数组，覆盖自动注入的值，专为测试或运行时动态决策设计。
-
app()->make(MyService::class)→ 走绑定规则 + 自动注入构造函数依赖 -
app()->resolve(MyService::class, ['$apiKey' => 'test-key'])→ 强制把$apiKey设为'test-key'，绕过容器原本的解析逻辑 - 在单元测试中用
resolve()注入 mock 对象很自然，但生产代码里滥用会导致依赖关系不透明，调试困难
没显式绑定也能自动解析？那得看类有没有依赖
Laravel 对“零配置”支持有限：如果一个类构造函数全是具体类（比如只有 Logger、Request），且这些类本身也满足零配置条件，那确实不用 bind 就能 make()；但只要出现接口类型提示（如 PaymentGatewayInterface），就必须显式绑定，否则报 Target [App\Contracts\PaymentGatewayInterface] is not instantiable。
- 控制器、事件监听器、任务类等 Laravel 自动管理的类，支持构造函数类型提示自动注入，但前提是它们的依赖已被容器知晓
- 自己写的普通工具类（比如
app/Services/ReportGenerator.php），即使没接口，也建议显式bind()，避免后期加依赖时突然崩掉 - 环境差异容易暴露问题：本地
APP_ENV=local可能因缓存或调试模式掩盖绑定缺失，上线production就报错
最常被忽略的是绑定时机和绑定粒度：不是“绑了就行”，而是“在 register 里绑对的类、用对的方式、配对的生命周期”。稍有偏差，问题会藏在请求链深处，比如第 3 层服务调用时才爆出连接失败，而不是启动时报错。
