事务必须在服务层封装，控制器只负责协调请求与响应；正确做法是用 EntityManagerInterface::transactional() 封装业务流程，确保原子性、复用性与一致性。
事务必须在服务层封装，不能写在控制器里
控制器只负责协调请求与响应，事务逻辑放在这里会导致复用困难、测试不可靠、边界模糊。一旦后续要从命令行或消息队列触发相同业务，就得重复写一遍事务控制——这是典型的设计泄漏。
正确做法是把整个业务流程（比如创建订单 + 扣减库存 + 记录日志）封装进一个服务方法，并注入 EntityManagerInterface。注意：不要用 $this->getDoctrine()->getManager() 临时获取 EntityManager，它可能返回非预期实例，尤其在多库场景下极易出错。
- 服务类构造函数中接收
EntityManagerInterface参数，由容器自动注入 - 所有数据库操作都通过该实例完成，确保共享同一连接和事务上下文
- 避免在自定义 Repository 中调用
beginTransaction()或flush()，会破坏事务一致性
优先用 transactional()，别手动写 try/catch
手动管理 beginTransaction() / commit() / rollback() 容易遗漏异常路径，尤其是忘记在 catch 块里调用 rollback()，导致连接卡住、事务挂起，最终拖垮数据库连接池。
EntityManager::transactional() 是 Doctrine 提供的“防呆”封装：它自动开启事务、执行闭包、成功则提交、失败则回滚并重新抛出异常。内部还会检测当前是否已在事务中，避免嵌套开启（Doctrine 不支持真嵌套事务）。
- 写法：
$em->transactional(fn() => { $em->persist($order); $em->flush(); }); - 若需传参，可用
use ($order, $inventory)绑定变量，或改用普通服务方法封装 - 不要捕获
\Exception就完事，必须覆盖\Throwable，否则 PHP 致命错误（如内存溢出）不会触发回滚
跨多个 Repository 操作天然共享事务，无需额外协调
只要所有 Repository 都通过同一个 EntityManagerInterface 实例获取（即都由容器注入，且未指定其他 manager），它们的操作就自动落在同一事务内。中间表插入、外键约束、级联操作都会被统一管控。
常见误解是给每个 Repository 单独开事务，或者试图用事件监听器“同步”多个事务——这不仅多余，而且危险。Doctrine 的 UnitOfWork 机制决定了：只要 flush() 在同一事务内调用，所有变更就是原子的。
- 例如：
UserRepository创建用户、ProfileRepository初始化资料、AttachmentRepository关联头像，全在$em->transactional()里即可 - 切记：自定义 Repository 构造函数里不要自行调用
$em->getConnection()->beginTransaction()，否则会干扰上层事务边界 - 如果用了多库（如
customer和default），那它们天然隔离——跨库事务需 DBAL 层手动协调，Doctrine ORM 不支持
多库场景下事务不跨 connection，别指望 ORM 自动处理
Doctrine 的事务绑定在 Connection 级别，不是 EntityManager 级别。当你配置了多个 entity manager（如 doctrine.orm.customer_entity_manager），它们各自持有独立的 Connection 实例，彼此事务完全隔离。
这意味着：你无法用单个 transactional() 同时保证两个库的数据一致性。比如“扣客户库余额 + 写日志库记录”，必须自己用 DBAL 的 Connection 手动控制，或者接受最终一致性（如发消息异步补偿）。
- 验证方式：
$em1->getConnection() !== $em2->getConnection()恒为 true - 命令行迁移也需显式指定：
php bin/console doctrine:migrations:migrate --em=customer - 注入时必须用完整 service ID：
@doctrine.orm.customer_entity_manager，不能只依赖EntityManagerInterface类型自动解析
