register 方法仅允许容器绑定操作，不可依赖未注册的核心服务；boot 方法才可安全使用已注册服务并执行初始化逻辑。
register 方法只负责绑定服务到容器
它在应用启动早期执行，此时 laravel 的核心服务（如 router、view、config）可能还没完全注册，所以不能依赖它们。你只能安全地做一件事：调用 $this->app->bind()、$this->app->singleton() 或 $this->app->instance() 等容器注册操作。
常见错误是这里尝试获取 $this->app->make('router') 或读取 config('app.debug') —— 很可能返回 NULL 或默认值，因为配置或服务尚未加载。
-
register()是“声明式”的：只说“将来要用这个类，用这个实现” - 不要在这里触发任何副作用（如写日志、发 http 请求、读数据库）
- 不要调用
$this->app->resolve()或$this->app->get()
boot 方法用于依赖已注册服务的初始化逻辑
它在所有 register() 执行完毕、容器已基本就绪后才运行。这时你可以安全使用 router、view、Event、config 等核心服务，也能访问你自己的服务（只要它们已在某个 register() 中绑定）。
典型用途包括：注册路由、监听事件、发布视图/配置、设置中间件、扩展 Blade 指令。
- 必须等
boot()做的事：比如用Route::get()注册路由 ——Route类依赖router服务，而该服务在register阶段尚未可用 - 可以在这里调用
$this->app->make('MyService')，前提是MyService已在某处register过 - 多个 Service Provider 的
boot()执行顺序由providers数组顺序决定，但都晚于全部register
加载顺序与依赖陷阱
Laravel 启动时严格按两阶段走：先全部 register → 再全部 boot。这意味着：
- AServiceProvider 的
register()和 BServiceProvider 的register()可能交错执行（取决于config/app.php中providers数组顺序），但都早于任何boot() - 如果你在 A 的
register()中试图$this->app->make('BService')，而 BService 是由 BServiceProvider 在其register()中绑定的 —— 这会失败，因为 B 的register()可能还没执行 - 正确做法：把对 BService 的依赖移到 A 的
boot()中，此时 BService 必然已绑定（只要 B 在 providers 数组中排在 A 前面，或即使后面，也因所有 register 已完成而确保可用）
class MyServiceProvider extends ServiceProvider { public function register() { // ✅ 安全：只绑定 $this->app->singleton(MyService::class, function ($app) { return new MyService(); }); // ❌ 危险：此时 config() 可能未就绪 // $debug = config('app.debug'); } public function boot() { // ✅ 安全：config、router、event 全部可用 if (config('my-package.enabled')) { Route::middleware('web')->group(function () { require __DIR__.'/routes.php'; }); } } }什么时候该把逻辑从 boot 移到 register
几乎不需要。只有极少数场景适合在 register() 做更多事，比如：
- 你想提前覆盖 Laravel 默认绑定（如用自定义
UrlGenerator替换原生的），必须在 Laravel 自己的register之前执行 —— 这时需调整providers数组顺序，并确保只做bind/singleton - 某些扩展包需要在容器构建早期注入解析器（如
$this->app->resolving()），这个回调注册本身可在register，但回调体里的逻辑仍要小心依赖
绝大多数业务初始化逻辑，包括依赖其他服务的操作，都应该留在 boot()。别为了“看起来更早”而提前执行，容易掉进容器状态不一致的坑里。