事务必须手动开启、显式提交或回滚，Doctrine 不会自动包裹控制器或服务方法；需通过 $em->getConnection()->beginTransaction() 获取连接并控制事务，多库不共享事务，@Transactional 注解仅对容器管理的服务生效且有诸多限制。
事务必须手动开启、显式提交或回滚，Doctrine 不会自动包裹控制器或服务方法。
手动 beginTransaction() 是唯一可靠起点
Doctrine 的 EntityManager 默认不开启事务上下文。哪怕你只执行一条 $em->persist() + $em->flush()，若没调 beginTransaction()，每个 SQL 语句都会自动 commit（即 auto-commit 模式）。这意味着：并发写入时无法保证原子性，中间出错也无法回退。
- 必须先获取连接对象：
$connection = $em->getConnection()，再调$connection->beginTransaction() - 不能只对
$em操作——$em->flush()只触发 SQL 执行，事务控制权在Connection层 - 多个 EntityManager（如主库/从库）不能共享事务，
replica连接调beginTransaction()会直接抛TransactionRequiredException
commit() 和 rollback() 必须成对出现在 try/catch 中
漏掉 catch 块里的 rollback()，或在 try 里提前 return，都会导致连接卡在 open transaction 状态，后续请求可能被锁表或超时。
- 正确结构：
try { ... $em->flush(); $connection->commit(); } catch (\Exception $e) { $connection->rollback(); throw $e; } - 不要用
finally做 commit/rollback——它无法区分成功还是失败路径 - 如果事务中调用了外部服务（如发邮件），建议把副作用操作移出事务块，避免事务长时间持有连接
@Transactional 注解只在特定条件下生效
DoctrineBundle 提供的 @Transactional 注解不是魔法开关。它依赖 AOP 代理和正确的服务配置，且仅对容器管理的服务方法起作用。
- 仅当该方法属于被 Symfony 容器管理的 service（非 controller 直接调用、非 new 出来的对象）时才拦截
- 注解默认使用
defaultEntityManager，无法指定replica_entity_manager或其他连接 - 若方法内手动调了
$em->getConnection()->beginTransaction()，注解会失效（双重事务控制冲突） - 生产环境若禁用了 debug 模式或未启用 DoctrineBundle 的 AOP 配置，注解完全不触发
事务内读写必须走同一连接，跨库查询会失败
这是最容易被忽略的硬限制：一旦进入事务，所有 DQL 查询、原生 SQL、Repository 方法都强制路由到当前事务所属的 Connection。试图在事务中切换到 replica 连接会立刻报错。
- 错误现象：
TransactionRequiredException: No transaction is currently active—— 实际含义是“你正用 replica 连接执行事务内操作，不被允许” - 写后立即读（如创建订单后查单号）必须用主库连接，否则可能读不到刚插入的数据（尤其主从延迟场景）
- 想缓解主库压力？只能把只读部分拆到事务外，或用
Connection::fetchOne()+ 显式关闭 auto-commit，但需自行处理隔离级别与一致性风险
真正安全的事务边界，永远由你显式划定；任何“自动”或“隐式”的假设，都会在高并发或主从架构下暴露问题。
