Laravel模型观察者？观察者怎样注册使用？-Laravel-PHP中文网

Laravel模型观察者用于集中处理模型生命周期事件，通过创建观察者类并注册到EventServiceProvider，实现创建、更新、删除等操作的业务逻辑解耦。观察者应保持轻量，通过委托服务、分发任务或事件来处理复杂逻辑，避免臃肿和无限循环，确保事务一致性和代码可维护性。

laravel模型观察者？观察者怎样注册使用？

Laravel模型观察者（Model Observers）提供了一种优雅的方式，用于将模型事件的监听逻辑集中到一个单一的类中。当你在处理模型创建、更新、删除等生命周期事件时，观察者能够让你以一种非常干净、可维护的方式来执行相关的业务逻辑。简单来说，它就像一个“管家”，专门负责在你模型发生特定行为时，去执行你预设好的操作。注册和使用它们非常直接，主要分为创建观察者类和在

EventServiceProvider

登录后复制

中将其绑定到模型。

解决方案

要使用Laravel模型观察者，你需要完成以下几个步骤：

创建观察者类： 你可以使用 Artisan 命令来快速生成一个观察者类。例如，如果你想为

User

登录后复制

模型创建一个观察者，可以运行：

php artisan make:observer UserObserver --model=User

登录后复制

这个命令会在

app/Observers

登录后复制

目录下创建一个

UserObserver.php

登录后复制

文件，并预填充了一些常用的事件方法（如

created

登录后复制

updated

登录后复制

deleted

登录后复制

等）。

观察者类中的每个方法都对应着模型的一个生命周期事件，并且会接收到被操作的模型实例作为参数。例如：

// app/Observers/UserObserver.php
namespace App\Observers;

use App\Models\User;

class UserObserver
{
    /**
     * 处理 User "creating" 事件。
     * 在模型保存到数据库之前触发。
     */
    public function creating(User $user): void
    {
        // 例如，在用户创建前设置一个默认值
        if (empty($user->status)) {
            $user->status = 'active';
        }
    }

    /**
     * 处理 User "created" 事件。
     * 在模型保存到数据库之后触发。
     */
    public function created(User $user): void
    {
        // 例如，新用户注册后发送欢迎邮件
        // Mail::to($user->email)->send(new WelcomeEmail($user));
        // 或者分发一个任务到队列
        // SendWelcomeEmailJob::dispatch($user);
    }

    /**
     * 处理 User "updating" 事件。
     * 在模型更新到数据库之前触发。
     */
    public function updating(User $user): void
    {
        // 检查特定字段是否被修改
        if ($user->isDirty('email')) {
            // 邮件地址变更后的处理逻辑
            // Log::info("User {$user->id} email is changing from {$user->getOriginal('email')} to {$user->email}");
        }
    }

    /**
     * 处理 User "updated" 事件。
     * 在模型更新到数据库之后触发。
     */
    public function updated(User $user): void
    {
        // 例如，用户资料更新后同步到外部系统
        // SyncUserService::sync($user);
    }

    /**
     * 处理 User "deleting" 事件。
     * 在模型从数据库删除之前触发。
     */
    public function deleting(User $user): void
    {
        // 例如，删除用户前清理相关数据
        // $user->posts()->delete();
    }

    /**
     * 处理 User "deleted" 事件。
     * 在模型从数据库删除之后触发。
     */
    public function deleted(User $user): void
    {
        // 例如，用户被删除后记录日志
        // Log::warning("User {$user->id} was deleted.");
    }

    /**
     * 处理 User "restoring" 事件。
     * 在模型恢复之前触发。
     */
    public function restoring(User $user): void
    {
        //
    }

    /**
     * 处理 User "restored" 事件。
     * 在模型恢复之后触发。
     */
    public function restored(User $user): void
    {
        //
    }

    /**
     * 处理 User "forceDeleted" 事件。
     * 在模型被强制删除之后触发。
     */
    public function forceDeleted(User $user): void
    {
        //
    }
}

登录后复制

注册观察者： 创建了观察者类之后，你需要在

App\Providers\EventServiceProvider

登录后复制

中注册它，告诉Laravel哪个观察者对应哪个模型。打开

app/Providers/EventServiceProvider.php

登录后复制

文件，在

boot

登录后复制

方法中添加以下代码：

// app/Providers/EventServiceProvider.php
namespace App\Providers;

use App\Models\User;
use App\Observers\UserObserver;
use Illuminate\Auth\Events\Registered;
use Illuminate\Auth\Listeners\SendEmailVerificationNotification;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;

class EventServiceProvider extends ServiceProvider
{
    /**
     * The event to listener mappings for the application.
     *
     * @var array<class-string, array<class-string>>
     */
    protected $listen = [
        Registered::class => [
            SendEmailVerificationNotification::class,
        ],
    ];

    /**
     * Register any events for your application.
     */
    public function boot(): void
    {
        // 在这里注册你的观察者
        User::observe(UserObserver::class);
        // 如果有其他模型，可以继续注册
        // Product::observe(ProductObserver::class);
    }

    /**
     * Determine if events and listeners should be automatically discovered.
     */
    public function shouldDiscoverEvents(): bool
    {
        return false;
    }
}

登录后复制

完成这些步骤后，每当

User

登录后复制

模型触发相应的生命周期事件时，

UserObserver

登录后复制

中对应的方法就会被自动调用。

为什么选择Laravel模型观察者而非事件监听器？

在我看来，模型观察者和事件监听器各有其适用场景，并非完全的替代关系，更多是互补。我个人倾向于在以下情况选择模型观察者：

集中管理模型相关逻辑： 当一个模型有多个生命周期事件（如创建、更新、删除）都需要执行一些特定逻辑时，观察者能将所有这些逻辑集中到一个类中。这让代码看起来更整洁，也更容易理解“当
```
User
```
登录后复制
模型发生变化时，会执行哪些操作”。它就像是模型的一个专属“行为日志”，所有对模型自身状态的响应都写在这里。
强耦合性与内聚性： 如果这些逻辑与模型的业务紧密相关，或者说这些操作是模型自身行为的直接延伸，那么观察者是很好的选择。例如，在用户创建时自动生成一个唯一的邀请码，或者在用户状态变为“禁用”时，自动清除其所有会话。这些都是围绕着
```
User
```
登录后复制
模型自身展开的。
代码可读性与维护性： 想象一下，如果把所有模型事件的监听器都散落在
```
EventServiceProvider
```
登录后复制
的
```
$listen
```
登录后复制
数组里，当项目变大后，你可能很难一眼看出某个模型到底有哪些“副作用”。观察者提供了一种更结构化的方式，让我能快速定位和修改某个模型的事件处理逻辑。

而事件监听器（Event Listeners）则更适合处理：

解耦的业务流程： 当一个事件的发生可能引发多个、相互独立的服务或组件的响应时。例如，用户注册成功（一个事件），可能需要发送欢迎邮件（服务A），更新用户统计数据（服务B），通知管理员（服务C）。这些操作可能由不同的团队负责，或者逻辑上完全不相关，这时分发一个
```
UserRegistered
```
登录后复制
事件，然后让多个监听器去响应，会更灵活。
跨模型的协作： 当一个模型的事件需要触发另一个模型的逻辑时。比如，订单状态变为“已完成”，需要去更新商品库存。如果用观察者，你可能需要在
```
OrderObserver
```
登录后复制
里直接操作
```
Product
```
登录后复制
模型，这会增加耦合。而通过
```
OrderCompleted
```
登录后复制
事件，
```
ProductInventoryListener
```
登录后复制
去监听，则更符合单一职责原则。

所以，我通常是这样思考的：如果逻辑是模型自身的“反应”，且高度内聚，我会考虑观察者。如果逻辑是“通知”其他系统或服务去执行操作，且需要高度解耦，那么事件和监听器是更优解。有时候，我甚至会在观察者内部再分发一个更具体的事件，将部分复杂逻辑进一步解耦。

Laravel模型观察者有哪些常见陷阱和最佳实践？

在使用模型观察者时，我踩过一些坑，也总结了一些经验，这里分享一些常见的陷阱和最佳实践：

常见陷阱：

观察者“臃肿症”： 这是最常见的陷阱。把过多的业务逻辑、甚至复杂的计算和外部API调用直接写在观察者方法里。这会导致观察者变得庞大、难以测试，并且让模型事件的处理变得缓慢。观察者应该像一个“指挥官”，而不是“执行者”。
- 问题表现： 一个
```
UserObserver
```
  登录后复制
  的
```
created
```
  登录后复制
  方法里，既发邮件又同步数据到CRM，还生成了PDF报告。
- 后果： 任何一个环节出错都会影响整个请求，且难以定位问题；测试时需要Mock大量依赖。
无限循环： 如果你在一个观察者方法里，又修改了它正在观察的模型，并且这个修改又触发了相同的事件，就可能导致无限循环。
- 例如： 在
```
UserObserver
```
  登录后复制
  的
```
updated
```
  登录后复制
  方法里，你修改了
```
$user->last_activity_at
```
  登录后复制
  ，然后调用
```
$user->save()
```
  登录后复制
  。这又会触发
```
updated
```
  登录后复制
  事件，再次调用
```
updated
```
  登录后复制
  方法，直到堆栈溢出。
- 规避方法： 在修改模型并保存时，使用
```
$user->withoutEvents(function () use ($user) { $user->save(); });
```
  登录后复制
  来暂时禁用事件，或者确保你的修改不会再次触发相同的观察者方法。
事务问题：
```
created
```
登录后复制
和
```
updated
```
登录后复制
事件是在模型被持久化到数据库之后触发的。这意味着如果你的数据库操作在一个事务中，而事务最终回滚了，观察者中执行的外部操作（比如发送邮件、调用第三方API）可能已经执行，但数据库状态却回滚了，导致数据不一致。
- 解决方案： 对于需要与数据库事务强一致性的操作，考虑使用
```
afterCommit
```
  登录后复制
  事件，或者在观察者中分发队列任务，让任务在事务提交后才执行。
过度耦合： 虽然观察者是为了集中逻辑，但如果观察者内部直接依赖了太多具体的服务或仓库，也会导致观察者本身变得难以复用和测试。

知我AI
一款多端AI知识助理，通过一键生成播客/视频/文档/网页文章摘要、思维导图，提高个人知识获取效率；自动存储知识，通过与知识库聊天，提高知识利用效率。

101

查看详情

最佳实践：

保持观察者精简： 观察者方法应该只做一件事：接收模型，然后将具体的业务逻辑委托给服务类、队列任务或分发新的事件。它应该是一个轻量级的协调者。

// Bad example (bloated observer)
public function created(User $user)
{
    // Lots of logic here
    Mail::to($user->email)->send(new WelcomeEmail($user));
    SomeApiService::syncUser($user);
    LogActivity::record($user, 'created');
}

// Good example (delegating to services/jobs)
public function created(User $user)
{
    // 委托给专门的服务
    app(WelcomeEmailService::class)->send($user);
    // 分发一个队列任务进行异步处理
    SyncUserToCrmJob::dispatch($user);
    // 分发一个事件，让其他监听器去响应
    UserCreated::dispatch($user);
}

登录后复制

使用构造函数注入依赖： 观察者类可以像控制器或服务一样，通过构造函数注入其所需的依赖。这使得观察者更易于测试和管理。

namespace App\Observers;

use App\Models\User;
use App\Services\WelcomeEmailService;

class UserObserver
{
    protected $welcomeEmailService;

    public function __construct(WelcomeEmailService $welcomeEmailService)
    {
        $this->welcomeEmailService = $welcomeEmailService;
    }

    public function created(User $user): void
    {
        $this->welcomeEmailService->sendWelcomeEmail($user);
    }
}

登录后复制

利用队列处理耗时操作： 任何可能耗时（如发送邮件、调用外部API、图片处理）或可能失败的操作，都应该通过队列任务来异步执行。这能保证HTTP请求的响应速度，并增加系统的健壮性。
```
use App\Jobs\SendWelcomeEmail;

public function created(User $user): void
{
    SendWelcomeEmail::dispatch($user)->onQueue('emails');
}
```
登录后复制
明确事件触发时机： 区分
```
creating/updating/deleting
```
登录后复制
（在数据库操作前）和
```
created/updated/deleted
```
登录后复制
（在数据库操作后）。如果你需要在保存前修改模型数据，用前者；如果需要模型ID或已保存状态，用后者。
- 例如，在
```
creating
```
  登录后复制
  中给模型设置默认值，在
```
created
```
  登录后复制
  中发送欢迎邮件。

条件性执行逻辑： 在

updating

登录后复制

或

updated

登录后复制

事件中，经常需要判断模型哪些字段发生了变化，只对感兴趣的字段变化做出响应。

public function updated(User $user): void
{
    if ($user->isDirty('email')) {
        // 只有当邮箱地址改变时才执行此逻辑
        // NotifyUserEmailChanged::dispatch($user, $user->getOriginal('email'));
    }
}

登录后复制

$user->isDirty('field_name')

登录后复制

可以检查特定字段是否被修改。

$user->getOriginal('field_name')

登录后复制

可以获取字段的原始值。

遵循这些实践，能让你的模型观察者成为一个强大的工具，而不是一个潜在的维护噩梦。

如何在Laravel模型观察者中处理复杂业务逻辑或外部服务调用？

处理复杂业务逻辑或外部服务调用是模型观察者最容易被误用的地方，也是最能体现其设计功力的地方。我的核心思路是：观察者只负责“观察”和“调度”，不负责“执行”具体的复杂任务。

这里有几种有效的方法来处理这些场景：

注入并调用服务层： 这是最直接且推荐的方式。将处理复杂逻辑的“服务类”（Service Class）注入到观察者的构造函数中。这样，当模型事件发生时，观察者只需调用服务类的方法即可。这保持了观察者的精简，并将复杂的业务逻辑封装在专门的服务中。

// app/Services/UserRegistrationService.php
namespace App\Services;

use App\Models\User;
use Illuminate\Support\Facades\Mail;
use App\Mail\WelcomeEmail;

class UserRegistrationService
{
    public function handleNewUser(User $user): void
    {
        // 复杂的欢迎流程，可能包括发送邮件、生成初始配置等
        Mail::to($user->email)->send(new WelcomeEmail($user));
        $this->createDefaultSettings($user);
        // ... 其他复杂的注册后逻辑
    }

    protected function createDefaultSettings(User $user): void
    {
        // 比如为新用户创建一些默认设置
        // $user->settings()->create(['theme' => 'dark', 'notifications' => true]);
    }
}

// app/Observers/UserObserver.php
namespace App\Observers;

use App\Models\User;
use App\Services\UserRegistrationService; // 引入服务类

class UserObserver
{
    protected $userRegistrationService;

    public function __construct(UserRegistrationService $userRegistrationService)
    {
        // 通过构造函数注入服务
        $this->userRegistrationService = $userRegistrationService;
    }

    public function created(User $user): void
    {
        // 观察者只负责调用服务层的方法
        $this->userRegistrationService->handleNewUser($user);
    }

    // ... 其他事件方法
}

登录后复制

这种方式使得

UserRegistrationService

登录后复制

可以独立测试，并且在其他地方（如API控制器）也可以复用。

分发队列任务（Jobs）： 对于任何耗时、需要异步处理、或者可能失败后需要重试的操作，分发队列任务是最佳选择。这包括发送邮件、处理图片、调用外部API（如支付网关、CRM系统同步）、生成报表等。将这些操作推入队列，可以显著提高应用程序的响应速度和用户体验。

// app/Jobs/SyncUserToCrm.php
namespace App\Jobs;

use App\Models\User;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use App\Services\CrmApiService; // 假设有一个CRM API服务

class SyncUserToCrm implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public $user;

    public function __construct(User $user)
    {
        $this->user = $user;
    }

    public function handle(CrmApiService $crmApiService): void
    {
        // 复杂的外部API调用逻辑
        $crmApiService->syncUser($this->user);
    }
}

// app/Observers/UserObserver.php
namespace App\Observers;

use App\Models\User;
use App\Jobs\SyncUserToCrm; // 引入队列任务

class UserObserver
{
    public function updated(User $user): void
    {
        if ($user->isDirty(['name', 'email', 'phone'])) {
            // 如果用户关键信息更新，则分发一个队列任务去同步到CRM
            SyncUserToCrm::dispatch($user)->onQueue('crm_sync');
        }
    }

    // ... 其他事件方法
}

登录后复制

队列任务还可以处理失败重试、延迟执行等高级特性，极大地增强了系统的鲁棒性。