应手写轻量观察者而非直接使用SplSubject/SplObserver，因其接口简陋、不支持传参与事件区分；推荐EventDispatcher类实现零依赖、可测、可复用的通知机制。
PHP 里怎么用 SplSubject / SplObserver 实现观察者
PHP 标准库（SPL）自带 SplSubject 和 SplObserver 接口，但直接用它们容易踩坑——不是不能用，而是接口太简陋，不支持传参、不区分事件类型、notify() 调用时 observer 拿不到上下文。
实操建议：只把它们当契约参考，别真靠 attach()/notify() 做业务逻辑。更靠谱的做法是手写轻量观察者，核心就三点：
- subject 维护一个
array $observers，类型可限定为callable或自定义接口 - 触发通知时，显式传入事件名和数据，比如
$this->notify('user.registered', ['user_id' => 123]) - observer 回调里自行判断是否响应该事件，避免全量广播
示例片段：
class EventDispatcher
{
private array $listeners = [];
public function on(string $event, callable $callback): void
{
$this->listeners[$event][] = $callback;
}
public function dispatch(string $event, array $data = []): void
{
foreach ($this->listeners[$event] ?? [] as $callback) {
$callback($data);
}
}
}
为什么不用 Laravel 的 Event 系统？
如果你项目已用 Laravel，event() 和 dispatch() 确实开箱即用，但代价是强耦合容器和自动发现机制——它依赖 EventServiceProvider、监听器需注册、事件类要继承 Illuminate\Foundation\Events\Dispatchable。
立即学习“PHP免费学习笔记（深入）”；
在非 Laravel 项目或 CLI 工具脚本里硬塞这套，会引入大量无用依赖，且调试时容易卡在 Container::resolve() 里。
更适合的替代方案：
- 纯函数式：定义
on_user_created()这样的命名回调，手动调用 - 简单类封装：像上面
EventDispatcher那样，零依赖、可测、可复用 - 如果真需要异步，优先考虑队列（如
amqp或redislist），而不是在观察者里塞sleep()或exec()
常见错误：在 __construct() 里触发 notify()
典型现象：对象刚 new 出来就报 Fatal error: Uncaught Error: Call to a member function update() on null，因为 observer 还没 attach 就 notify 了。
根本原因在于生命周期错位——构造函数里无法保证依赖已就绪。
正确做法：
- 把
notify()移到明确的业务动作之后，比如save()成功后 - 用工厂或 Builder 模式控制初始化顺序，确保 subject 和 observer 同时存在再绑定
- 避免在 setter 或魔术方法（如
__set()）中隐式触发通知，容易导致递归或状态不一致
PHP 8.1+ 属性升级对观察者的影响
PHP 8.1 引入 readonly 属性，有人想用它保护 subject 的 $observers 数组，结果发现 readonly array 一旦赋值就不能 push 新 observer。
这不是 bug，是设计使然：readonly 仅防止属性重赋值，不阻止数组内部修改。但你不能写 $this->observers[] = $o，因为 PHP 把这视为对整个数组的“写操作”。
所以：
- 别给观察者列表加
readonly，用常规private array $observers = []即可 - 如果真要防御性编程，可用
ArrayObject封装，并在attach()中做类型检查 - 注意
__serialize()和__unserialize()不会自动重建 observer 关系，反序列化后的 subject 是“裸体”的，得手动 re-attach
观察者模式真正的复杂点不在语法，而在于谁负责清理 observer 引用——PHP 的 GC 不会自动解绑闭包里的 $this，长期运行的服务容易内存泄漏。这点很容易被忽略。
