最常用、最安全的起点是直接用 EntityManager::getRepository() 调用 Doctrine 默认查询方法，如 find()、findOneBy()、findBy() 和 findAll()，无需写 SQL 或 DQL，前提是 User 实体已正确映射且 Repository 未被覆盖。
直接用 EntityManager::getRepository() 调用标准方法
最常用、最安全的起点是调用 Doctrine 默认提供的查询方法，不需要写 SQL 或 DQL。前提是你的 User 实体已正确映射且 Repository 未被覆盖。
常见场景和对应调用：
-
find($id)：按主键查单个用户，返回User对象或null -
findOneBy(['email' => $email])：按字段查一个用户，支持多个条件（如['email' => $email, 'isActive' => true]） -
findBy(['isActive' => true], ['createdAt' => 'DESC'], 10)：查多个用户，支持排序和限制数量 -
findAll()：全量查，慎用于生产环境（无分页、无条件）
这些方法底层走的是 ORM 映射元数据，自动处理表名、字段映射、关联预加载（需显式配置），不会触发 N+1（除非你后续访问了未 fetch 的关联属性）。
需要复杂条件时用 QueryBuilder 构建动态查询
当 findBy 不够用——比如要 JOIN 关联表、用 LIKE 模糊搜索、或组合 AND/OR 嵌套条件——就该上 QueryBuilder。它比原生 SQL 安全，又比 DQL 更易调试。
典型做法是在 UserRepository 中封装方法：
$qb = $this->createQueryBuilder('u');
$users = $qb
->where('u.email LIKE :pattern')
->andWhere('u.isActive = :active')
->setParameter('pattern', '%' . $keyword . '%')
->setParameter('active', true)
->getQuery()
->getResult();
注意点：
- 别在 Controller 里直接 new QueryBuilder，破坏关注点分离
- 所有变量必须用
setParameter()绑定，避免 SQL 注入 - 如果只查部分字段（如 ID 和姓名），用
select('u.id', 'u.username')，避免加载整个实体对象 - 关联查询（如查用户及其角色）用
leftJoin('u.roles', 'r')，Doctrine 自动识别中间表
查不到数据？先确认实体是否被 Doctrine 管理
常见“查不到”不是逻辑问题，而是配置或状态问题：
-
User类没加@ORM\Entity注解，或没在doctrine.yaml的mappings里声明路径 - 数据库表名与实体映射不一致（比如注解写了
@ORM\Table(name="app_users")，但实际表是users） - 实体实现了
UserInterface但没实现getUsername()或getPassword()，导致某些安全相关查询失败 - 使用了自定义 Repository 类，但忘记在实体注解里指定
@ORM\Repository("App\Repository\UserRepository")
快速验证方式：运行 php bin/console doctrine:schema:validate，看是否报 “The mapping files are invalid”。
从数据库连接层查（绕过 ORM）仅限特殊场景
极少数情况需要跳过 ORM，比如执行批量更新、查视图、或兼容遗留字段命名。这时用 Connection：
$conn = $this->getEntityManager()->getConnection();
$stmt = $conn->executeQuery('SELECT id, username FROM users WHERE email = ?', [$email]);
$user = $stmt->fetchAssociative(); // 返回关联数组
但要注意：
- 返回值是数组，不是
User对象，无法调用实体方法或触发生命周期回调 - 字段名必须和数据库一致，不经过 Doctrine 的列映射转换
- 事务需手动管理（
$conn->beginTransaction()），ORM 的@Transactional不生效 - 别用它做常规用户查询——失去缓存、变更跟踪、类型转换等 ORM 优势
真正难的不是“怎么查”，而是“查完怎么用”。比如序列化用户时漏掉 @Groups 配置，导致 JSON 输出空对象；或者在 API 响应中直接返回 User 实体，意外暴露密码哈希字段。这些细节比查询语法更常引发线上问题。
