监听器优先级必须为整数且按降序执行，传播拦截仅对实现stoppableeventinterface的事件生效；stoppropagation()仅跳过后续监听器，不回滚已执行逻辑，也不替代业务异常处理。
监听器优先级必须设为整数，且传播拦截只在实现了 StoppableEventInterface 的事件上生效——否则调用 $event->stopPropagation() 会被静默忽略。
监听器优先级不是越大越“重要”，而是越先执行
Symfony 的 EventDispatcher 按优先级降序排列监听器：数值为 10 的监听器一定比 5 的先执行，-5 的比 0 的晚执行。这和某些前端框架（如 Cocos2d-x）的“越小越优先”逻辑相反，容易混淆。
- 第三方 Bundle 可能注册了高优先级监听器（比如
security.authentication.success监听器常设为255），你自定义的拦截逻辑若设为0就永远赶不上 - 优先级相同的情况下，注册顺序决定执行顺序（FIFO），但这个行为不可靠，不应依赖
- 不要用浮点数或字符串当优先级——
addListener()第三个参数强制为int，传错类型会触发 PHP 类型警告（PHP 8.0+）
stopPropagation() 不等于“取消事件”，它只影响后续监听器
stopPropagation() 不会回滚已执行的监听器逻辑，也不会改变事件对象本身的状态。它只是让调度器跳过当前事件名下剩余未执行的监听器。
- 如果你在低优先级监听器里调用
$event->stopPropagation()，前面高优先级的监听器早已执行完毕，无法撤回 - 必须确保事件类实现
StoppableEventInterface，否则方法存在但无实际效果；常见错误是继承了Event却没显式实现该接口 - 调试时可用
$event->isPropagationStopped()检查是否已被拦截，避免重复判断
事件溯源场景下，优先级 + 传播拦截要配合状态快照
做事件溯源（Event Sourcing）时，你通常需要确保「状态变更监听器」在「日志记录监听器」之前执行，且一旦状态校验失败就终止整个链路——这时优先级和传播控制必须协同设计。
- 状态校验监听器优先级设为
100，日志监听器设为0，确保前者先跑、有机会拦停 - 校验失败时调用
$event->stopPropagation()，并手动抛出异常（如InvalidStateException），避免后续监听器误以为操作成功 - 不要依赖事件传播拦截来替代业务异常处理——它不提供事务语义，也不保证原子性
最易被忽略的一点：事件对象是否真正实现了 StoppableEventInterface，比优先级数字本身更关键。很多团队花半天调优先级，最后发现事件类根本没声明接口，stopPropagation() 一直是个空操作。
