服务容器是对象创建与依赖管理的调度中心，只存创建逻辑而非实例；bind()注册工厂、singleton()缓存单例、instance()硬塞实例；接口绑定须在register()中完成且确保Provider已注册。
服务容器不是“容器”，是对象创建与依赖管理的调度中心
它不存对象，只存创建逻辑（闭包、类名、实例等），真正用到时才执行构造。很多人以为 app()->bind() 是把实例塞进内存，其实只是注册一个“怎么造这个东西”的配方。
- 绑定后不触发构造函数，
app()->make(ClassName::class)才真正实例化 - 单例绑定（
singleton()）才缓存实例；普通bind()每次调用都新建 - 若绑定的是字符串类名（如
'cache'），Laravel 会自动解析为Illuminate\Contracts\Cache\Factory接口对应实现，这依赖config/app.php中的providers和接口绑定规则
bind()、singleton()、instance() 的区别直接决定内存和行为
这三个方法看着像只是“存东西”，但底层策略完全不同：一个是工厂模式，一个是单例模式，一个是硬塞实例。
-
bind('foo', function ($app) { return new Foo(); })→ 每次make('foo')都执行闭包，得到新对象 -
singleton('foo', function ($app) { return new Foo(); })→ 首次make后缓存结果，后续返回同一实例 -
instance('foo', new Foo())→ 直接存住你给的实例，不走任何构造逻辑，也不检查是否已存在 - 误用
instance()绑定未初始化的依赖（比如没设置好数据库连接的DB实例），会导致后续make()返回一个不可用对象
接口绑定失效？先查 config/app.php 里的 Service Provider 是否注册
写 $this->app->bind(RepositoryInterface::class, EloquentRepository::class) 没用，大概率是因为 Laravel 根本没加载这段代码——服务提供者没被注册，或者注册时机太晚（比如在 boot() 里绑接口，但某些组件已在 register() 阶段提前解析过）。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 接口绑定应放在
AppServiceProvider::register()方法内，确保早于所有依赖解析 - 检查
config/app.php的providers数组是否包含你的AppServiceProvider（默认有，但自定义 provider 容易漏） - 如果用的是包开发，别在
boot()里做接口绑定，此时容器可能已开始解析依赖，导致绑定被跳过 - 验证是否生效：用
php artisan tinker运行app()->resolved(RepositoryInterface::class)返回true表示已绑定成功
resolve() 和 make() 看似一样，但参数处理逻辑不同
make() 只接受服务名（字符串或类名），resolve() 可传入具体参数数组，用于覆盖自动注入的值，适合测试或动态上下文场景。
-
app()->make(MyService::class)→ 完全依赖类型提示和容器自动解析 -
app()->resolve(MyService::class, ['host' => '127.0.0.1'])→ 强制将$host参数传给构造函数，绕过配置或环境变量 - 注意：
resolve()不走绑定逻辑，它只做“带参构造”，若类没在容器中注册绑定，也不会报错，而是直接 new —— 这容易掩盖绑定缺失问题 - 调试时可用
app()->build(MyService::class)查看实际构造过程，但别在生产用，它不走单例缓存
绑定逻辑藏得深，但关键就三点：什么时候注册（register）、注册什么（接口还是实现）、怎么取（make 还是 resolve）。漏掉任一环，依赖就断在看不见的地方。
