Service Provider 是 Laravel 容器绑定与服务初始化的唯一受控入口，核心职责为 register() 中绑定接口到实现、boot() 中执行依赖已就绪的扩展操作；它不是注册器、启动脚本，不处理业务逻辑或 HTTP 请求。

Service Provider 是什么，不是什么

Service Provider 不是“注册器”或“启动脚本”，它是 Laravel 容器绑定与服务初始化的**唯一受控入口**。它不负责执行业务逻辑，也不该直接处理请求或返回响应。它的核心职责只有两个：register() 中绑定接口到实现，boot() 中执行依赖已就绪的扩展操作（比如监听事件、发布配置、注册中间件）。

什么时候必须写自己的 Service Provider

当你需要以下任一场景时，才应新建 Provider：

• 将一个自定义接口（如 PaymentGateway）绑定到具体实现（如 StripeGateway），并希望在控制器中通过类型提示自动解析
• 在应用启动后、所有服务都已注册完毕时，执行依赖容器的服务初始化（例如：向 Validator 添加自定义规则、为 Event 注册监听器）
• 封装第三方包的集成逻辑（比如集成 spatie/laravel-permission 时，它自带的 PermissionServiceProvider 就做了模型绑定和迁移发布）

别为了“组织代码”而强行拆出 Provider——把工具类静态方法塞进 register()，或在 boot() 里调用 Artisan::call('migrate')，都是典型误用。

register() 和 boot() 的关键区别与陷阱

register() 执行极早，此时 Laravel 的大部分服务（如 DB、Config、Request）尚未可用；boot() 才真正“启动完成”，所有绑定都已就绪。这个顺序直接影响你能否安全调用其他服务。

常见错误示例：

public function register()
{
    // ❌ 错误：Config 尚未加载，这里取不到 config('app.debug')
    if (config('app.debug')) {
        $this->app->bind(LoggerInterface::class, DebugLogger::class);
    }
}

正确做法：

• 只在 register() 做纯绑定：$this->app->singleton(MyService::class, function ($app) { return new MyService($app->make(Helper::class)); });
• 把依赖运行时状态的判断（如环境、配置值）移到 boot()，或使用闭包延迟求值
• 若需条件绑定，用 when(...)->needs(...)->give(...)，它比 if 判断更安全

绑定方式选型：singleton、bind、instance、alias 怎么选

不同绑定方式影响对象生命周期与解析行为，选错会导致内存泄漏或状态污染：

• $this->app->singleton()：最常用。每次解析都返回同一个实例（适合无状态服务，如 Mailer、Cache）
• $this->app->bind()：每次解析都新建实例（适合有请求上下文的状态对象，如 Request 或自定义的 Cart）
• $this->app->instance()：手动传入一个已存在对象，容器后续只返回它（适合复用外部创建的 SDK 客户端，如 new GuzzleHttp\Client()）
• $this->app->alias()：仅为某个类起别名（如 $this->app->alias('cache', CacheManager::class)），不推荐用于业务逻辑绑定

特别注意：bind() 不等于 “每次 HTTP 请求新建一次”。Laravel 容器默认是单例作用域，除非你显式用 bind() 并配合 request-scoped 解析逻辑（比如在中间件中重新绑定），否则仍可能复用实例。