Laravel 6观察者默认不被容器自动解析，需手动用app()或resolve()获取服务，或通过app(UserObserver::class)注册以支持构造函数注入，推荐依赖下沉至Service层。
Laravel 6 的观察者（Observer）类默认**不会被服务容器自动解析**，因此不能像控制器或请求类那样直接通过构造函数类型提示注入业务服务。这是因为 Laravel 在注册模型事件监听时，是直接 new 实例化观察者（如 new UserObserver），而非从容器中 resolve。但你仍可以通过几种方式安全、规范地在观察者中使用业务服务。
手动从容器解析服务（最常用）
在观察者方法内部，使用 app() 或 resolve() 获取所需服务实例。这种方式简单直接，适用于大多数场景：
- 确保业务服务已正确绑定到容器（例如在
AppServiceProvider@register中） - 避免在构造函数中硬编码依赖，保持观察者轻量
- 推荐只在真正需要时解析，避免无谓开销
示例：
namespace App\Observers;
use App\Models\User;
use App\Services\UserNotificationService;
use App\Services\UserAnalyticsService;
class UserObserver
{
public function created(User $user)
{
// ✅ 从容器获取服务
$notification = app(UserNotificationService::class);
$analytics = resolve(UserAnalyticsService::class);
$notification->sendWelcomeEmail($user);
$analytics->trackRegistration($user);
}
}
在观察者构造函数中注入（需配合容器注册）
若希望观察者本身也被容器管理（支持构造函数注入），你需要主动用容器实例化它，并手动注册为模型观察者：
- 在
AppServiceProvider@boot中，不调用User::observe(UserObserver::class) - 改用
User::observe(app(UserObserver::class))，这样容器会先解析并注入依赖 - 前提是
UserObserver的构造函数参数能被容器识别和解析（如类型提示了已绑定的服务）
示例：
// 在 AppServiceProvider.php 的 boot() 方法中
public function boot()
{
// ❌ 原始写法：绕过容器
// User::observe(UserObserver::class);
// ✅ 改为容器解析后注册
User::observe(app(UserObserver::class));
}
// 对应的观察者类
class UserObserver
{
private $emailService;
private $logger;
public function __construct(EmailService $emailService, LoggerInterface $logger)
{
$this->emailService = $emailService;
$this->logger = $logger;
}
public function updated(User $user)
{
$this->emailService->notifyProfileUpdated($user);
$this->logger->info('User profile updated', ['user_id' => $user->id]);
}
}
使用闭包绑定 + 静态工厂（适合复杂初始化）
当观察者依赖动态参数（如配置、运行时值）时，可在服务提供者中用闭包绑定一个“工厂”：
- 定义一个可调用的闭包，返回已注入依赖的观察者实例
- 再将该闭包绑定到容器，供
app()调用 - 最后在
boot()中使用app('user.observer')注册
示例（简化版）：
// AppServiceProvider@register()
$this->app->bind('user.observer', function ($app) {
return new UserObserver(
$app->make(EmailService::class),
$app->make('config')->get('features.notify_enabled')
);
});
// AppServiceProvider@boot()
User::observe(app('user.observer'));
不推荐的方式：全局辅助函数或静态属性
避免在观察者中使用 new UserService() 或静态缓存服务实例，原因包括：
- 破坏依赖注入原则，难以测试和替换实现
- 无法享受单例、生命周期管理等容器特性
- 若服务本身有依赖（如数据库连接、配置），手动 new 容易出错
不复杂但容易忽略的是：观察者本质是事件回调载体，职责应聚焦于响应模型变化；业务逻辑务必下沉到 Service 层，并由容器统一协调。
