php中直接使用splsubject/splobserver接口虽省事但参数固定，notify()无法传递业务数据；建议自定义update($event)方法并封装事件，配合try-catch、异步处理、闭包观察者及统一事件规范。
PHP里用SplSubject和SplObserver接口最省事
PHP标准库自带 SplSubject 和 SplObserver，不用自己从零写接口。但直接用它们有个硬伤：attach()、detach()、notify() 的参数签名固定，比如 notify() 只能传 $subject，没法顺手带业务数据。
常见错误现象：notify() 里想读订单ID或用户状态，结果发现 $this->subject 是个空壳对象，或者得在观察者内部再查一遍数据库。
- 如果业务逻辑简单、通知内容只和被观察对象本身有关，直接实现这两个接口就行
- 如果需要传递额外上下文（比如事件类型、变更字段、请求ID），建议放弃原生接口，自定义
update($event)方法，把事件封装成数组或轻量对象 - 注意
SplObjectStorage在attach()时用对象作键，所以观察者实例不能重复添加——但很多人会无意识在循环里反复$subject->attach(new Logger())，导致通知多次
手动实现观察者时，别让Subject持有Observer的引用链
容易踩的坑是 Subject 类里用数组存 Observer 实例，然后在 notify() 里 foreach 调用 $observer->update()。这看起来没问题，但一旦某个 update() 抛出未捕获异常，整个通知链就断了，后面注册的观察者全收不到消息。
使用场景：日志记录、缓存失效、消息队列投递——这些环节一个失败不该阻塞其他。
立即学习“PHP免费学习笔记（深入）”；
- 加 try-catch 包裹每个
$observer->update()调用，异常记录到error_log()或监控系统，但不中断循环 - 避免在
update()里做耗时操作（如远程HTTP请求、大文件写入），否则拖慢主流程；异步处理要另起进程或交由队列 - 别在 Observer 构造函数里反向调用 Subject 的方法（比如自动注册），容易引发循环依赖或构造未完成就通知
用__invoke让闭包当观察者更灵活
不是所有观察逻辑都值得单独建类。比如临时加个调试钩子、或只在某次请求中监听，用匿名函数更轻量。
PHP 支持把闭包当对象用，只要它实现了 __invoke() 方法（所有闭包天然支持）。
- 注册时直接
$subject->attach(function($event) { var_dump($event['type']); }); - Subject 的
notify()里判断is_callable($observer)或用$observer->__invoke($data)都行，推荐后者，语义更清晰 - 注意闭包捕获的变量生命周期：如果用了
use ($logger)，而 $logger 是 request-scoped 对象，那下次请求时这个观察者可能失效 - 无法 detach —— 除非你把闭包存进变量再传进去，否则没引用可删；生产环境慎用无名闭包作长期监听
事件名称和数据结构必须约定清楚
观察者模式崩坏的起点，往往不是代码，而是没人说清“到底发什么、谁来接、怎么解”。比如一个订单状态变更，有人发 ['status' => 'paid']，有人发 ['old' => 'pending', 'new' => 'paid']，观察者全靠猜字段。
性能影响：字段嵌套过深、序列化体积大、JSON 编码慢；兼容性影响：新增字段后老观察者报错或静默忽略。
- 统一用小写字母+下划线命名事件名，如
order_status_changed、user_profile_updated - 事件数据强制为关联数组，顶层键固定为
event、timestamp、payload，业务数据全塞进payload - 在 Subject 基类里加
assertEventSchema()方法，开发环境校验必填字段，避免漏传关键信息
最麻烦的其实是跨模块协作时，没人愿意改自己的 Observer 去适配新事件格式——这事得靠早期约定，而不是后期补文档。
