Laravel 6 中服务提供者必须严格匹配文件路径、类名与命名空间，register() 仅限绑定服务，boot() 才可使用 config/DB 等依赖，多提供者绑定同一接口时后注册者覆盖前者，defer=true 需显式实现 provides() 且无副作用。
服务提供者类名和命名空间必须严格匹配文件路径
放错位置或写错命名空间是 Laravel 6 中最常导致“Class not found”或服务不生效的根本原因。Laravel 6 不支持自动扫描子目录，app/Providers 是唯一被框架默认信任的目录。
常见错误现象：Class App\Providers\CustomLoggerServiceProvider does not exist——这几乎总是因为以下之一：
- 文件实际放在
app/Helpers/CustomLoggerServiceProvider.php，但命名空间仍写成App\Providers - 类名是
CustomloggerServiceProvider（小写 l），而文件名是CustomLoggerServiceProvider.php（大写 L），在 Linux 环境下直接报错 - 改过
composer.json的 autoload 配置但没运行composer dump-autoload
务必确认三者完全一致：文件路径、文件名、类名、命名空间。
register() 里调用 config() 或 DB 就会出问题
Laravel 6 的 register() 执行时机非常早，此时 config、db、log 等核心服务都还没注册进容器。把读配置或查数据库的逻辑塞进去，轻则报 Target class [config] does not exist，重则让 php artisan migrate 直接失败。
正确分工如下：
-
register()只做绑定：$this->app->singleton(MyService::class, function ($app) { ... }) -
boot()才能安全使用：config('myapp.timeout')、Event::listen()、Blade::component() - 如果绑定的是 Eloquent 模型或依赖数据库的服务，必须挪到
boot()
多个服务提供者绑同一个接口时谁生效？
后注册的覆盖先注册的——Laravel 容器不会合并或报错，而是静默替换。比如两个提供者都执行了：
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
$this->app->bind(LoggerInterface::class, CustomLogger::class);
那么最后加载的那个提供者决定最终绑定结果。调试时容易误判，建议：
- 用
php artisan tinker运行app()->resolved('Psr\Log\LoggerInterface')查看是否已解析 - 在每个
register()里加Log::debug('CustomLoggerServiceProvider registered')确认加载顺序 - 避免多个提供者竞争同一接口；如需多实现，改用 tagged bindings +
collect($this->app->tagged('logger'))->each(...)
延迟服务提供者（defer = true）不是万能优化
设 public $defer = true 后，Laravel 会跳过自动发现，必须显式实现 provides() 方法返回所绑定的类或接口。否则该提供者根本不会被加载。
适用场景很窄：
- 只做单一绑定（例如只 bind 一个 SDK 客户端）
- 不执行任何副作用（不监听事件、不注册命令、不修改全局状态）
- 绑定的服务确实不是每次请求都用得上（比如导出 Excel 的专用服务）
一旦你在 provides() 里漏写某个绑定项，或者在 register() 里偷偷调用了 config()，延迟加载就会失效或报错——这种问题在测试环境难复现，上线后才暴露。
