应仅对明确“非启动必需”且“使用频率低”的服务启用延迟加载，如第三方API客户端、图像处理服务、自定义日志驱动；禁止对数据库、缓存、事件、路由等基础服务延迟，否则会导致boot()失败或BindingResolutionException。
延迟加载服务提供者不是“开了就快”，而是得看它是否真被用到、是否影响启动耗时、是否破坏了依赖顺序——盲目 defer 可能导致 boot() 逻辑失效或服务未注册就被调用。
什么时候该用延迟加载？
只对明确「非启动必需」且「使用频率低」的服务启用延迟加载，比如：
- 第三方 API 客户端（如
wechat.client、payment.gateway），仅在支付页或后台定时任务中用到 - 图像处理服务（
image.processor），只在上传头像或生成缩略图时触发 - 自定义日志驱动（
custom.logger），仅在 debug 模式下启用
不要对数据库、缓存、事件、路由等基础服务做延迟——它们在 register() 阶段就要绑定，否则后续引导（boot()）会报 BindingResolutionException。
两种实现方式：$defer = true vs DeferrableProvider
Laravel 5.5+ 推荐实现 DeferrableProvider 接口，它比直接设 $defer = true 更可靠，因为框架会主动检查 provides() 返回的服务名是否真实存在绑定。
必须同时满足以下三点才生效：
- 类实现
Illuminate\Contracts\Support\DeferrableProvider - 重写
provides()方法，返回该提供者注册的所有服务键名（如['sms.sender', 'notification.channel']） - 确保这些键名与
register()中实际绑定的完全一致（大小写、拼写、点号都不能错）
示例：
use Illuminate\Contracts\Support\DeferrableProvider;
class SmsServiceProvider implements DeferrableProvider
{
public function register()
{
$this->app->singleton('sms.sender', function ($app) {
return new SmsClient($app['config']['sms']);
});
}
public function provides()
{
return ['sms.sender']; // 必须和 bind 的 key 严格一致
}
}
延迟后为什么服务还是立刻加载了？
常见原因有三个：
- 你在
config/app.php的providers数组里把它放在了「非延迟提供者」前面，而 Laravel 启动时会按顺序执行所有register()——哪怕它标了defer，只要被提前 require 到，PHP 就会加载类并触发静态分析，导致延迟失效 - 其他服务在
register()阶段就通过$this->app->make('sms.sender')主动取用了这个服务，强制提前实例化 - 你没清缓存：
php artisan config:clear和php artisan clear-compiled（Laravel 9+ 改为php artisan opcache:clear）必须执行，否则bootstrap/cache/services.php里缓存的非延迟列表不会更新
延迟加载对队列任务的影响
这点特别容易被忽略：延迟加载的服务，在队列 Worker 进程中首次调用时才注册。如果该服务依赖某些运行时上下文（比如请求对象、session、auth 用户），而队列是无状态的 CLI 进程，register() 里用的 $app['request'] 就会报错或返回空值。
解决办法只有两个：
- 把依赖项从构造函数移到方法内（懒加载），比如在
send()里再app('request') - 改用非延迟方式注册，但在
boot()里用app()->resolving('sms.sender', ...)做条件初始化
别指望 delay() 队列任务能自动触发延迟服务加载——它和 HTTP 请求生命周期完全隔离。
