延迟加载服务提供者必须实现deferrableprovider接口并重写provides()方法，否则defer无效；register()中禁止读配置、调服务或查数据库，所有操作须移至boot()；启用defer后需手动注册到config/app.php并运行config:cache。
延迟加载服务提供者必须实现 DeferrableProvider
不实现这个接口，defer = true 就是无效的。Laravel 只认接口契约，不是靠属性开关自动识别。实现后还要重写 provides() 方法，明确返回该提供者负责绑定的类或接口名，比如 [PaymentService::class, PaymentGateway::class]。漏掉任意一个，容器在解析依赖时会找不到对应实例，直接抛出 Target class [PaymentService] does not exist。
register() 里不能读配置、不能调其他服务、不能碰数据库
延迟提供者看似“晚执行”，但它的 register() 仍运行在容器注册阶段——此时 config、db、cache 这些核心服务都还没就绪。常见错误包括：
- 在
register()中写config('payment.timeout')→ 报错Target class [config] does not exist - 调用
$this->app->make(EventDispatcher::class)→ 同样失败，因为事件服务在更晚才注册 - 执行
Schema::hasTable()或模型查询 →ConnectionException或空连接
所有这类操作必须挪到 boot()，哪怕你用了 defer。延迟只影响“是否提前加载类文件和执行 register()”，不改变方法执行时机的约束。
延迟提供者不会被 php artisan package:discover 自动注册
这是最容易被忽略的一点：启用 defer 后，Laravel 自动发现机制（即扫描 app/Providers 目录）会跳过该类。你必须手动把它加进 config/app.php 的 providers 数组，否则它根本不会被加载。即使类文件存在、命名规范、接口也实现了，没进数组就是零存在感。
顺带提醒：改完 config/app.php 后，别忘了跑 php artisan config:cache，否则新注册项在生产环境不会生效。
延迟加载不是万能的，副作用代码会破坏预期
如果你的提供者在 register() 里做了除绑定外的事——比如写日志、发 HTTP 请求、创建临时目录、修改全局状态——那开启 defer 会导致这些动作推迟到第一次真正用到该服务时才执行。这可能引发竞态、重复执行，或者让某些本该在启动时完成的初始化被遗漏。延迟只适合纯绑定场景：单一接口、无外部依赖、无副作用。一旦有 if 判断环境、file_put_contents、Redis::set 这类操作，就别碰 defer。
