Doctrine ORM 查询流程为元数据解析→DQL编译→SQL生成→参数绑定→执行→结果映射；实体元数据驱动动态SQL生成；DQL面向对象，经SqlWalker转为方言SQL；QueryBuilder构建DQL，EntityManager管理缓存与持久化。
Doctrine ORM 的查询不是“直接执行 SQL”，而是经过元数据解析→DQL编译→SQL生成→参数绑定→执行→结果映射这一完整流程。理解这个链条，才能真正掌握为什么 find() 很快、findOneBy() 可能慢、而 N+1 查询会拖垮性能。
实体与元数据是查询的起点
每个实体类（如 Product）通过注解（@ORM\Entity, @ORM\Column）或 YAML 定义结构，Doctrine 在启动时加载并缓存其元数据（ClassMetadata 实例）。这个对象包含：表名、主键字段、字段类型、关联关系、是否可为空等全部映射信息。查询方法（如 find($id)）内部会查元数据确认主键列名，再拼出类似 SELECT * FROM product WHERE id = ? 的 SQL —— 这不是硬编码，而是动态推导。
DQL 是面向对象的查询语言，不是 SQL 的别名
DQL（Doctrine Query Language）操作的是实体和属性，而非表和字段。例如：
-
SELECT u FROM App\Entity\User u JOIN u.posts p——u是 User 实体实例，u.posts是其一对多关联属性； - Doctrine 解析该 DQL 后，根据元数据知道
User映射到user表、posts关联由post.user_id外键维护，最终生成带JOIN的标准 SQL； - 所有 DQL 查询都经由
Doctrine\ORM\Query类处理，它调用SqlWalker（SQL 行走器）将抽象语法树（AST）翻译为具体数据库方言的 SQL。
Repository 封装的是查询构建逻辑，不是执行入口
当你调用 $repository->findByName('foo')，实际执行的是：
- Repository 方法内通常使用
$this->createQueryBuilder()创建QueryBuilder对象； -
QueryBuilder不执行查询，只收集条件（where）、排序（orderBy）、参数（setParameter）等； - 调用
->getQuery()->getResult()才真正触发 DQL 编译与执行； - 关键点：
QueryBuilder本质是 DQL 字符串的构造器，它的expr()提供安全的表达式拼接（防注入），而非字符串拼接。
EntityManager 是状态管理中枢，不是数据库连接池
EntityManager 维护着当前请求生命周期内的一级缓存（Identity Map）和工作单元（Unit of Work）：
-
find(1)第一次查，走数据库；第二次查同一 ID，直接从内存缓存返回，不发 SQL； -
persist()把新对象注册进 Unit of Work；flush()才批量计算 INSERT/UPDATE/DELETE 语句并提交； - 这意味着：没调
flush()，数据不会入库；多次persist()同一对象，也不会重复插入； - 也意味着：手动改了数据库表结构但没更新实体元数据，
flush()可能静默失败或写错字段。
