Laravel模型观察者用于解耦模型生命周期事件处理，通过创建观察者类、定义事件方法（如created、updating）并在AppServiceProvider中注册，实现对模型操作的响应。选择观察者适合处理与模型紧密相关的逻辑，而事件监听器更适合跨模块的解耦场景。saving在保存前执行，可修改数据或阻止操作；saved在保存后执行，宜用于发送通知等副作用。预事件中抛异常可回滚事务，后事件建议异步处理或捕获异常以保障主流程。
Laravel的观察者模式，特别是模型观察者（Model Observers），是一种优雅地处理模型生命周期事件的机制。它允许你将这些事件的监听逻辑从模型本身抽离出来，集中管理，从而让你的模型代码更简洁，职责更单一。简单来说，当你的Eloquent模型在创建、更新、删除等操作发生时，观察者会像一个忠实的“管家”一样，自动执行你预设好的操作。这对于维护数据一致性、触发副作用或者进行审计日志等场景，提供了一个非常清晰且低耦合的解决方案。
使用Laravel模型观察者来监听和响应Eloquent模型生命周期事件，核心在于创建观察者类，定义事件方法，并将其注册到对应的模型上。
1. 创建观察者类
你可以通过Artisan命令快速生成一个观察者类。例如，如果你想为
User
php artisan make:observer UserObserver --model=User
这个命令会在
app/Observers
UserObserver.php
2. 定义事件方法
在生成的
UserObserver
以下是一些常用的事件方法及其作用：
retrieved(User $user)
creating(User $user)
create()
created(User $user)
updating(User $user)
update()
updated(User $user)
saving(User $user)
saved(User $user)
deleting(User $user)
deleted(User $user)
restoring(User $user)
restored(User $user)
如果你在
creating
updating
deleting
saving
false
<?php
namespace App\Observers;
use App\Models\User;
use Illuminate\Support\Facades\Log;
class UserObserver
{
/**
* Handle the User "created" event.
*/
public function created(User $user): void
{
// 当用户创建后，发送欢迎邮件或记录日志
Log::info("新用户 {$user->name} ({$user->email}) 已注册。");
// Mail::to($user->email)->send(new WelcomeEmail($user));
}
/**
* Handle the User "updating" event.
*/
public function updating(User $user): bool
{
// 假设我们不允许用户将邮箱修改为特定域名
if (str_ends_with($user->email, '@example.com') && $user->isDirty('email')) {
Log::warning("用户 {$user->id} 尝试将邮箱修改为禁止的域名。");
return false; // 阻止更新操作
}
return true;
}
/**
* Handle the User "deleted" event.
*/
public function deleted(User $user): void
{
// 当用户删除后，清理相关数据或通知管理员
Log::info("用户 {$user->name} ({$user->id}) 已被删除。");
// $user->posts()->delete(); // 删除用户所有帖子
}
/**
* Handle the User "retrieved" event.
*/
public function retrieved(User $user): void
{
// 可以在这里对模型进行一些初始化操作，比如设置一个非数据库字段
$user->is_admin_cached = ($user->role === 'admin');
}
}3. 注册观察者
观察者类创建并定义好方法后，需要将其注册到对应的模型上。这通常在
App\Providers\AppServiceProvider
boot
<?php
namespace App\Providers;
use App\Models\User;
use App\Observers\UserObserver;
use Illuminate\Support\ServiceProvider;
class AppServiceProvider extends ServiceProvider
{
/**
* Register any application services.
*/
public function register(): void
{
//
}
/**
* Bootstrap any application services.
*/
public function boot(): void
{
// 注册User模型的观察者
User::observe(UserObserver::class);
// 如果有其他模型，可以继续注册
// Post::observe(PostObserver::class);
}
}完成以上步骤后，每当
User
UserObserver
这确实是个让人纠结的问题，毕竟两者都能在模型事件发生时执行逻辑。我个人在实际开发中，会根据业务逻辑的耦合度和事件的广度来做选择。
模型观察者（Model Observers） 更适合那些与特定模型紧密相关的业务逻辑。比如说，一个用户被创建后，你需要给这个用户发送欢迎邮件；一个订单状态更新后，需要同步库存。这些操作通常只关心当前模型本身的变化，并且逻辑相对集中。观察者将这些逻辑封装在一个类中，使得模型本身保持“瘦身”，职责单一，代码看起来也更整洁。在我看来，观察者就像是模型的“专属管家”，只负责管理这个模型自己的事情。它提供的事件钩子非常直观，直接对应模型的生命周期。
事件监听器（Event Listeners） 则更适用于解耦度更高、跨多个模块或服务的业务场景。当一个事件发生时，可能有多个完全不相关的模块都需要响应，或者这个事件本身就是一个更抽象的“领域事件”。例如，一个“用户登录成功”的事件，可能需要记录登录日志、更新用户活跃时间、检查是否有未读通知，甚至触发一些第三方服务的调用。这些响应逻辑可能分散在不同的服务或组件中，通过事件分发器（Event Dispatcher）和监听器，可以实现非常松散的耦合。事件监听器就像是一个“广播站”，事件是广播内容，而监听器是收音机，不同的收音机可以根据自己的需求接收和处理广播。
我的选择倾向：
有时候，两者甚至可以结合使用。比如，观察者在模型
created
saving
saved
这是个非常实际的问题，我在写业务逻辑时也经常需要思考。
saving
saved
saving(Model $model)
这个钩子是在模型即将被保存到数据库之前触发的。无论是
create()
update()
saving
特点：
INSERT
UPDATE
saving
$model
saving
false
created
updated
何时使用：
creating
saved(Model $model)
这个钩子是在模型已经成功保存到数据库之后触发的。这意味着
INSERT
UPDATE
特点：
saved
$model->save()
何时使用：
我的建议：
如果你的逻辑需要在数据入库前进行修改或校验，并且有可能阻止操作，请使用
saving
creating
updating
saved
created
updated
理解这两个钩子的执行时机和能力边界，能让你更精确地控制模型行为，避免不必要的复杂性和潜在的bug。
在观察者中处理异常和确保数据一致性，是构建健壮应用的关键。说实话，这块常常被新手忽略，直到生产环境出现奇怪的数据问题才追悔莫及。
1. 预事件（creating
updating
deleting
saving
这些“ing”结尾的事件方法，因为发生在数据库操作之前，所以它们提供了最好的机会来阻止一个可能导致数据不一致的操作。
抛出异常： 如果在这些方法中检测到严重的业务逻辑错误或数据不合法，直接抛出一个异常是最好的方式。Laravel的Eloquent会捕获这些异常，并且默认会回滚当前正在进行的数据库事务（如果操作是在事务中执行的话）。
public function creating(User $user): void
{
if (User::where('email', $user->email)->exists()) {
// 抛出自定义异常，或者直接使用通用的异常
throw new \InvalidArgumentException('该邮箱已被注册。');
}
}当这个异常被抛出时，
User::create()
$user->save()
返回 false
false
false
2. 后事件（created
updated
deleted
saved
这是最需要小心的地方。因为这些事件是在模型已经成功保存到数据库之后触发的。如果在这里抛出异常，模型的数据库操作已经完成并提交。这意味着，即使你的观察者逻辑失败了，模型数据也已经写入了数据库。
异步处理： 对于那些不影响模型核心业务流程，但又可能失败的副作用（如发送邮件、同步到第三方系统），我强烈建议将它们放入队列中异步处理。这样，即使队列任务失败，也不会影响主业务流程的成功。
public function created(User $user): void
{
// 将发送欢迎邮件的任务推送到队列
SendWelcomeEmail::dispatch($user)->onQueue('emails');
}队列任务有重试机制，并且失败后可以记录日志，让你有时间去修复和处理。
数据库事务的边界： 如果你在后事件中执行了额外的数据库操作，并且希望这些操作与模型的保存操作保持原子性，那么你需要明确地将它们包裹在一个数据库事务中。
public function created(User $user): void
{
\DB::transaction(function () use ($user) {
// 假设用户创建后，需要自动创建一个默认的个人资料记录
$user->profile()->create([
'bio' => '默认个人简介',
'avatar' => 'default.jpg'
]);
// 如果这里出现异常，只会回滚 profile 的创建，user 的创建不会被回滚
// 如果你需要 user 也回滚，那么整个 user 创建的逻辑也需要包裹在事务中
});
}但更常见的做法是，如果后事件的逻辑是核心且必须与主模型操作原子化，那么应该将整个主模型操作及其所有相关的原子化逻辑都包裹在一个大的事务中。
异常捕获与日志： 对于那些无法异步化，但又不能阻止主流程的后事件逻辑，至少要做好异常捕获和日志记录。
public function updated(User $user): void
{
try {
// 尝试同步用户数据到外部CRM系统
$this->crmService->syncUser($user);
} catch (\Exception $e) {
// 记录错误，但不要重新抛出，以免影响主流程
Log::error("同步用户 {$user->id} 到CRM失败: " . $e->getMessage());
// 可以通知管理员
// Mail::to('admin@example.com')->send(new AdminAlert($e));
}
}这种方式确保了即使副作用失败，主业务流程也能继续，但你需要有监控和告警机制来及时发现并处理这些失败。
总结一下，对于观察者中的异常处理，我的经验是：预事件抛异常，后事件做异步或细致的事务管理，并始终做好日志记录。 明确每个事件钩子的执行时机和事务上下文，是避免数据不一致和系统不稳定的关键。
以上就是Laravel观察者模式？模型观察者如何使用？的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
164
收藏
