Behavior 的 beforeSave 事件先于 Table 的 beforeSave 触发，因 EventManager 按 addBehavior() 顺序注册监听器，Behavior 优先；$entity 为同一实例，修改可见但需正确标记 dirty；异常会短路后续所有监听器。
Behavior 的 beforeSave 和 Table 的 beforeSave 事件谁先触发
Behavior 的 beforeSave 一定早于 Table 类中定义的 beforeSave 事件回调执行。这是 CakePHP 事件调度器的硬性顺序：所有附加 Behavior 的事件监听器会先被注册并优先触发，之后才轮到 Table 自身的事件监听逻辑。
常见误判是以为在 Table 中用 $this->addBehavior('Timestamp') 后，自己的 beforeSave 方法会“覆盖”或“后置”，其实不会——它只是新增一个监听器，且排在 Behavior 之后。
- 行为类中重写的
beforeSave()方法（如TimestampBehavior::beforeSave()）属于事件监听器，走EventManager流程 - Table 类里直接定义的
beforeSave()是通过EventDispatcherTrait自动绑定的监听器，注册时机晚于 Behavior - 若多个 Behavior 都实现
beforeSave，按addBehavior()的调用顺序依次执行
Behavior 修改 $entity 属性后，Table 的 beforeSave 拿不到最新值？
能拿到，但前提是没在 Behavior 中用 $entity->setDirty() 或 $entity->setOriginal() 扰乱脏字段状态。CakePHP 的 beforeSave 流程中，$entity 是同一个实例，所有修改都作用于它本身。
典型陷阱是：某个 Behavior 在 beforeSave 中设置了字段但没标记为 dirty，导致后续保存时该字段被忽略。
立即学习“PHP免费学习笔记（深入）”；
- 务必用
$entity->set('field', $value)+$entity->setDirty('field', true)组合，否则字段可能不进 SQL - 避免在 Behavior 中调用
$entity->unsetProperty('field')，这会删掉属性而非清空值，Table 层读取时可能报 Notice - 调试时可在 Table 的
beforeSave回调里加debug($entity->toArray())确认字段是否已存在
多个 Behavior 都监听 beforeSave，如何控制执行优先级
CakePHP 不提供声明式优先级配置（比如 priority=10），执行顺序完全由 addBehavior() 的调用顺序决定。先 add 的 Behavior，其事件监听器先触发。
如果你依赖 A 行为必须在 B 行为之前处理字段，就不能靠注释或文档约定，得靠代码顺序保证。
- 在
initialize()中严格按依赖顺序调用：$this->addBehavior('Timestamp')→$this->addBehavior('MyCustomLogic') - 避免在
beforeFilter或其他运行时逻辑中动态addBehavior()，这会让顺序不可控 - 若需条件性启用 Behavior，改用
loadBehavior()并确保只在initialize()中统一加载
Behavior 的事件里抛异常，Table 的 beforeSave 还会执行吗
不会。一旦任意 beforeSave 监听器（包括 Behavior 或 Table 自身）抛出异常，整个保存流程立刻中断，后续所有监听器都不再执行。这是事件系统默认的“短路”行为。
这点容易被忽略：你以为自己 Table 里的校验逻辑兜底了，结果 Behavior 先崩了，根本没机会跑。
- Behavior 中的异常应尽量收敛，比如用
if (!$entity->has('required_field')) { throw new RuntimeException(...); } - 如果需要协同校验，建议把共用逻辑抽成独立方法，在 Behavior 和 Table 的
beforeSave中分别调用，而不是各自 throw - 日志中看到
Exception: ... in TimestampBehavior.php on line X，就说明问题出在 Behavior 层，Table 层的断点根本不会命中
