symfony doctrine读写分离必须显式配置连接名（如default和replica），读操作需手动指定replica连接，事务中强制走主库，从库延迟需业务层兜底。
在 Symfony 中分离读写操作不能靠 Doctrine 自动识别“读”或“写”，必须显式控制连接、事务边界和查询路径——否则所有查询默认走主库，读写分离形同虚设。
Doctrine 主从连接必须手动定义 connection 名，不能依赖语义标签
很多人在 doctrine.yaml 里写 replica: true 或给连接加注释，结果 $em->getRepository(User::class)->findAll() 依然查主库。因为 Doctrine 不解析这类标记，它只认你明确定义的 connections 下的连接名。
- 必须在
doctrine.dbal.connections下声明至少两个连接，例如default（主）和replica（从），每个都带完整url、host、user -
doctrine.orm.entity_managers.default.connection指向default，这是默认 EM 绑定的连接 - 环境变量要各自独立：确保
DATABASE_URL和DATABASE_URL_REPLICA都能被正确解析，否则启动时抛ConnectionException
读操作必须显式使用 replica 连接，EntityManagerInterface 默认不切换
注入的 EntityManagerInterface 实例永远绑定 default 连接。想走从库，只有两种可靠方式：
- 用服务容器获取独立的 EM 实例：定义
doctrine.orm.replica_entity_manager，并设其connection为replica；然后在控制器或服务中按需注入它 - 临时直连：调用
$this->getDoctrine()->getConnection('replica')，再用executeQuery()或fetchFirstColumn()执行原生 SQL - 别试图调
$em->getConnection()->setHost()动态改 host —— 连接对象已初始化，改了也不生效
事务内所有查询强制走主库，replica 连接进事务直接报错
只要当前请求存在事务（比如用了 @Transactional 注解、或手动调了 $em->beginTransaction()），Doctrine 就会拒绝让 replica 连接执行任何查询。典型错误是 TransactionRequiredException: No transaction is currently active，实际意思是“你拿从库连接想干事务里的事，不行”。
- 事务中读写必须在同一连接上，Doctrine 不支持跨连接事务
- read-after-write 场景（如创建订单后立即查）必须走主库，哪怕只读字段
- 规避方法只有把读操作拆到事务外，或用
Connection::fetch*+ 显式关闭自动 commit，但易出错，不推荐
从库延迟导致数据不一致，业务层必须兜底
即使连接和路由都配置正确，从库复制延迟仍会导致刚写入的数据查不到。这不是 Symfony 或 Doctrine 的问题，而是 MySQL/PostgreSQL 主从架构固有特性。
- 不能假设“写完立刻可读”，尤其在用户注册后跳转个人页、或支付成功后查订单状态等场景
- 常见兜底策略：对关键 read-after-write 查询，降级走主库；或引入短时重试 + 指数退避
- 如果用 Redis 做二级缓存，注意 Redis Cluster 的读写分离配置也要同步校验，避免缓存与 DB 状态错位
最常被忽略的一点：读写分离不是开关一开就见效的架构升级，而是贯穿连接管理、事务设计、缓存策略和最终一致性处理的整套协作。任何一个环节松动，性能提升就会打折扣，甚至引发数据异常。
