Repository类不应直接依赖EntityManager，应将数据操作逻辑拆至服务类，仅保留基础查询方法；自定义查询优先用createQueryBuilder()；测试时用内存SQLite与SchemaTool建表，Repository需定义接口并避免业务逻辑。
Repository类不该直接依赖EntityManager
直接在Repository里用$this->getEntityManager()或注入EntityManagerInterface会让单元测试难以隔离。Doctrine的EntityRepository本身只是个轻量代理，真正执行SQL的是EntityManager和Connection，一旦耦合，mock成本陡增。
实操建议：
- 把数据操作逻辑拆到独立的服务类（如
UserRetrievalService），Repository只保留find()、findBy()等基础方法 - 若必须自定义查询，优先用
createQueryBuilder()而非原生SQL——它返回QueryBuilder对象，可在测试中被替换成哑实现 - 避免在Repository构造函数里做任何非初始化行为（比如预加载配置、调用外部API）
用doctrine/orm的TestDouble替代真实数据库
跑真实DB测试慢、不稳定、难并行；但完全绕过ORM又失去对DQL语法、关联映射、生命周期回调的验证。折中方案是用Doctrine\ORM\Tools\SchemaTool + 内存SQLite，配合Repository的接口抽象。
实操建议：
- 为关键Repository定义接口（如
UserRepositoryInterface），在测试中用Mockery::mock()或PHPUnit的createMock()生成实现 - 集成测试时用
SqliteMemory连接：sqlite:///:memory:，再用SchemaTool::createSchema()快速建表 - 注意
clear()和flush()调用顺序：测试前$em->clear()重置UoW，避免实体状态污染
避免在Repository里做业务判断或转换
常见错误是把DTO构建、权限校验、分页计算塞进Repository，导致方法签名膨胀（如findActiveUsersForAdminWithPagination()），既违反单一职责，又让测试不得不模拟一堆上下文。
实操建议：
- Repository方法名聚焦数据动作：
findByStatus()、findOneByEmail()，不带角色、状态码、格式化等业务语义 - 分页交给
Pagerfanta或KnpPaginatorBundle在Controller或Service层处理，Repository只返回Query或QueryBuilder - DTO组装放在Assembler或Mapper类里，Repository返回原始实体或数组（用
getQuery()->getScalarResult()需谨慎，丢失类型信息）
测试自定义DQL时重点核对参数绑定与别名
手写DQL最常出错的是参数占位符不匹配（:status vs $status）、JOIN别名冲突、或GROUP BY字段遗漏，这些在测试里不显式断言就容易漏掉。
实操建议：
- 用
getDQL()和getParameters()检查生成的语句结构，而不是只测结果数量 - 对含
IN条件的查询，传入空数组时确认是否抛出InvalidParameterTypeException，并针对性覆盖该case - 关联查询务必在测试数据中显式设置双向关系（如
$user->addRole($role)），否则leftJoin()可能因无数据而静默失败
实际最难的不是写测试，是让团队接受“Repository只管查，不管为什么查”。很多边界case（比如缓存穿透、乐观锁失败重试）会自然推着你把逻辑往外移——这时别硬塞回Repository，那条线划清楚了，测试才真正可维护。
