Symfony 3 中数据库模型生命周期回调本质是 Doctrine ORM 提供的机制，需在实体类添加 @ORM\HasLifecycleCallbacks 注解并正确映射，回调方法按时机触发且禁止在其中调用 flush() 或修改实体状态。
Symfony 3 中的数据库模型生命周期回调，本质是 Doctrine ORM 提供的机制，不是 Symfony 自身功能，但通过 Symfony 的 Doctrine 集成可直接使用。关键在于实体类正确声明、方法标注清晰、触发时机匹配，且不能在回调里调用 flush() 或修改当前实体状态。
必须加 @HasLifecycleCallbacks 注解
Doctrine 不会自动扫描实体方法，必须显式启用监听：
- 在实体类顶部（
class User上方）添加@ORM\HasLifecycleCallbacks - 确保该类已正确映射为实体：有
@ORM\Entity注解，且路径被doctrine.orm.mappings配置覆盖 - 如果用 XML/YAML 映射，需在映射文件中配置
<lifecycle-callbacks>节点，而非注解
常用回调类型和适用场景
每种回调只在特定持久化阶段触发，不能混用：
-
@ORM\PrePersist：对象首次写入数据库前，适合生成 UUID、设置创建时间、初始化默认字段 -
@ORM\PostPersist：数据已入库但事务未提交，适合发通知（不改实体）、记录日志（只读） -
@ORM\PreUpdate：仅当字段实际变化时触发（Doctrine 比较变更集），适合更新updatedAt -
@ORM\PostLoad：每次从数据库加载后都执行（包括find()、关联查询、refresh()），适合反序列化 JSON 字段或懒初始化属性 -
@ORM\PreRemove：$em->remove($user)+flush()流程中触发，适合清理关联资源（如删除头像文件）
回调里能做什么、不能做什么
看似灵活，但限制明确，违反易导致死循环或异常：
- ✅ 可安全操作：设置当前实体字段（如
$this->updatedAt = new \DateTimeImmutable()）、调用外部服务（如日志器、邮件服务）、读取其他实体（只读） - ❌ 严禁操作：调用
$em->flush()、修改当前实体主键或标识字段、向 EntityManager 添加/删除其他实体 - ⚠️ 替代方案：需要跨实体写操作或异步任务，改用 Symfony 事件系统，监听
postPersist等事件，在监听器中调用flush()
测试时别忘了走完整流程
单元测试中直接 new 实体并调方法，回调不会执行 —— 因为没经过 Doctrine 管理流程：
- 验证回调逻辑，必须用真实
EntityManager，调用persist()+flush() - 推荐用功能测试（functional test）或集成测试（integration test），启动内存数据库模拟真实场景
- 调试时可在回调里加
dump($this); die;，但上线前务必移除
