Doctrine实体不更新主因是未调用flush()或字段设为updatable=false；需确保实体被管理、显式flush、检查映射配置、排查异常与缓存干扰。
Doctrine ORM 的实体不更新，通常不是 Symfony 本身的问题，而是 Doctrine 持久化层的变更跟踪机制没被触发，或者开发者误以为“改了 PHP 对象就等于改了数据库”。
Doctrine 不自动同步对象修改到数据库
Doctrine 默认使用“变更集（change set）”机制：只有在 EntityManager::flush() 被调用时，它才比对当前对象状态和上次 persist() 或 find() 时的快照，生成 SQL。单纯给实体属性赋值（比如 $user->setName('Alice')）不会立即写库。
- 必须显式调用
$em->flush()，且该 EntityManager 实例已管理该实体（即实体由find()查出，或已persist()过） - 若实体是新创建的（
new User()），需先$em->persist($user)，再flush() - 若实体来自
find()，但之后被detach()或clear()过，再修改也不会被跟踪
实体字段映射未启用可写（read-only 字段）
常见于使用 @ORM\Column(updatable=false) 或 readonly=true 配置的字段。这类字段在 flush() 时会被跳过，即使你改了值也不会生成 UPDATE 语句。
- 检查实体类中对应字段的注解或 YAML/XML 映射，确认没有
updatable=false或insertable=false - 特别注意主键、时间戳字段（如
createdAt）常被设为只读；若真要更新，得手动移除该配置 - Doctrine 会静默忽略这些字段的变更——不会报错，也不会写库，这是最容易被忽略的“无感失败”
事务中途抛出异常但未回滚或未捕获
如果在 flush() 前后有未处理的异常（例如验证失败、唯一约束冲突、数据库连接中断），Doctrine 默认会回滚整个事务，导致看似“执行了但没生效”。
- 运行时查看日志：
bin/console doctrine:query:sql "SELECT * FROM user WHERE id = 1"确认数据库实际值 - 在
flush()周围加 try/catch，并打印$e->getMessage()，很多“不更新”其实是UniqueConstraintViolationException导致静默失败 - 注意：Symfony 默认开发环境日志级别可能不显示 DBAL 底层错误，需检查
var/log/dev.log中是否有SQLSTATE[23000]类错误
缓存或代理对象状态混乱
Doctrine 的一级缓存（EntityManager 内存缓存）和二级缓存（如 Redis）可能导致你查到的是旧对象，或 flush() 后仍读到未刷新的副本。
- 调试时可用
$em->refresh($entity)强制从数据库重载最新值，验证是否真没更新 - 开发阶段建议禁用二级缓存（
doctrine.orm.second_level_cache.enabled: false），排除干扰 - 避免跨请求复用 EntityManager 实例；每次 HTTP 请求应使用新实例（Symfony 默认如此）
最常被忽略的点：Doctrine 不是“实时数据库镜像”，它是一套带状态的对象图管理器。改完属性后忘调 flush()，或字段被标记为 updatable=false，这两者占了实体不更新问题的八成以上。别猜，先查日志、再 refresh()、最后核对映射配置。
