服务容器是Laravel手动注册、自动解析依赖的调度中心；依赖注入将对象创建逻辑外移，bind每次新建实例适合无状态类，singleton全局单例适合高开销对象；构造函数需类型提示才能被反射解析；make尊重单例，resolve强制重建；手动new会绕过容器导致注入失效。
服务容器不是“魔法盒”，而是 Laravel 里你手动注册、框架自动解析依赖的调度中心；依赖注入也不是语法糖，是把对象创建逻辑从类内部抽出来交给容器管理——不理解这点，光背 bind 和 resolve 没用。
怎么注册一个可被自动注入的类（bind vs singleton）
注册方式直接决定实例生命周期和线程安全。用错会导致状态污染或性能浪费。
-
bind每次解析都新建实例，适合无状态工具类，比如JsonResponseBuilder -
singleton全局只建一次，适合数据库连接、缓存客户端这类开销大且可复用的对象 - 别在
bind里传闭包却返回单例对象，这会误导后续维护者——该用singleton就用singleton - 接口绑定必须显式声明，比如
$this->app->bind(LoggerInterface::class, MonologLogger::class)，否则注入LoggerInterface会报Target [Psr\Log\LoggerInterface] is not instantiable
构造函数参数怎么被自动填上（__construct 注入原理）
Laravel 不靠注解或配置文件推断依赖，而是用 PHP 的反射（ReflectionClass）读取构造函数签名，再递归解析每个类型提示的类。
- 必须带类型提示，
function __construct(CacheManager $cache)✅，function __construct($cache)❌（无法推断） - 如果某参数有默认值（如
array $options = []），它会被跳过解析，不会去容器里找array - 遇到接口或抽象类，容器会检查是否已绑定实现；没绑定就尝试实例化——失败则抛
Illuminate\Contracts\Container\BindingResolutionException - 不要在构造函数里调
$this->app->make()手动取依赖，这是反模式，破坏自动解析链条
什么时候该用 make，什么时候该用 resolve（运行时动态获取）
make 是标准解析入口，resolve 是它的语法糖，但行为有关键差异：后者会忽略容器中已有的单例缓存，强制重新构建。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 绝大多数场景用
$this->app->make(MyService::class)，它尊重singleton绑定 - 只有测试或极少数需“全新干净实例”的场景才用
resolve，比如每次都要隔离状态的命令行任务 - 别在循环里反复
make同一个单例类——没坏处但语义不清；更别用resolve替代make来“绕过单例”，那是设计缺陷 - 如果
make报Class xxx does not exist，先查命名空间拼写、自动加载是否生效，而不是怀疑容器配置
依赖注入失效的典型现场（new Xxx() 是最大破环者）
只要手动 new，就等于绕过容器，所有依赖都不会被注入，哪怕类本身写了完整类型提示。
- 控制器方法里写
$service = new PaymentService();→PaymentService的构造函数参数全为null或报错 - 静态工厂方法（如
User::fromArray()）返回新实例时，同样跳过容器，得改成$this->app->make(User::class)->fromArray(...) - 队列任务的
handle方法参数支持自动注入，但如果你在内部new了别的类，那部分仍不受控 - 测试中用
Mockery::mock()替换依赖时，记得在容器里instance进去，否则注入的还是真实类
真正卡住人的从来不是 bind 怎么写，而是哪一行代码悄悄用了 new，或者哪个接口忘了在 AppServiceProvider 里绑定实现——这些地方没报错，只是逻辑静默错乱。
