将旧系统sql/dao迁至symfony+doctrine需重构数据访问层：先用doctrine:mapping:import反向生成实体并显式声明表名、字段、主键；再用repository方法、dql或querybuilder替代字符串拼接查询，避免n+1，视图设readonly，归档表用原生查询，审计日志用事件监听器。
把旧系统里散落的 SQL、手写 DAO 或裸 PDO 查询，改成 Symfony 2 + Doctrine 的标准模式，不是简单替换语法，而是重构数据访问层的职责边界和可维护性。核心是两件事：结构对齐、逻辑升维。
先让数据库结构“说话”
旧库表结构是起点，不是包袱。Doctrine 不会自动理解你那张叫 user_info_ext 的扩展表到底对应哪个实体，得让它“认出来”：
- 用
doctrine:mapping:import --force把现有表反向生成带注解的 Entity 类，别跳过@ORM\Table(name="user_info_ext")这种显式声明 - 检查每个字段是否都加了
@ORM\Column，漏一个，doctrine:migrations:diff就可能忽略它，后续 DQL 查询会报“Unknown field” - 如果旧表主键不是
id，比如是uid，必须在 Entity 里明确写@ORM\Id @ORM\Column(name="uid")，否则find()直接失效
把查询从字符串拼接升级为对象表达
旧代码里常见的 "SELECT * FROM user WHERE status = '".$status."'"，风险高、难测试、无法复用。换成 Doctrine 模式后，逻辑更清晰：
- 单条查 ID？直接用
$repo->find($id)——不用写 SQL，不担心注入，还自带一级缓存 - 按多个字段查？用
findOneBy(['status' => $status, 'type' => $type])，条件自动转成参数绑定，空值也安全 - 要分页+排序？
findBy([], ['createdAt' => 'DESC'], 10, 0)一行搞定，不用手动算 offset - 原来用
mysql_query()执行的统计脚本？改用 DQL：SELECT COUNT(p.id) FROM Product p WHERE p.isArchived = true，再调getSingleScalarResult()
复杂查询交给 QueryBuilder，但别绕开语义
不是所有查询都适合写死 DQL。当条件来自用户输入（比如搜索框），QueryBuilder 是更可控的选择：
- 每个动态条件单独判断：
if ($minPrice) { $qb->andWhere('p.price >= :minPrice')->setParameter('minPrice', $minPrice); } - 多对多“与”关系筛选（如“红色且大号”）？必须用两个独立 JOIN 别名：
join('p.attributes', 'a1')和join('p.attributes', 'a2')，再分别加条件 - 避免 N+1：想查订单并带上用户姓名？用
leftJoin('o.user', 'u')->addSelect('u.name')，而不是在循环里反复调$order->getUser()->getName()
视图和归档数据要“特殊对待”
旧系统常把复杂逻辑塞进视图或历史表，迁过来不能硬套实体规则：
- 映射视图时，实体类顶部加
@ORM\Entity(readOnly=true)，去掉@ORM\Id或只设逻辑主键，否则 DQL 解析失败 - 查归档数据（比如
orders_2024_q4）？别试图让 Doctrine 管理这张表。在 Repository 里用原生连接：$conn->fetchAllAssociative("SELECT * FROM orders_2024_q4 WHERE ...") - 审计日志类操作？别在 Controller 里手写 INSERT。用 Doctrine 事件监听器，在
postUpdate里记录变更字段和操作人，结构化写入audit_log表
不复杂但容易忽略：每次改完查询逻辑，都要跑一遍旧接口对比结果，尤其注意 NULL 处理、时间格式、大小写敏感这些细节。重构不是为了炫技，是让下一个人接手时不骂娘。
