dql本身不防sql注入，必须配合参数绑定；用户输入须通过setparameter()绑定，禁用字符串拼接，字段名等非参数化部分需白名单校验。
直接用 DQL 不能防 SQL 注入——只有配合参数绑定才能防。DQL 本身是字符串，拼接用户输入就等于开门揖盗。
为什么 DQL 字符串里不能拼接变量
DQL 操作的是实体和属性，不是表和字段，但语法仍是字符串。一旦把 $_GET['id'] 或 $request->query->get('sort') 直接插进 DQL 字符串，比如：
SELECT p FROM App\Entity\Product p WHERE p.id = ' . $_GET['id']
就完全绕过了 Doctrine 的预处理机制，等同于裸写 SQL。Doctrine 不会解析、不校验、不拦截——它只负责把这串字符串交给数据库执行。
- 所有用户可控输入（路由参数、查询参数、表单值）必须走
setParameter() -
setParameters()接收数组时，键名必须与 DQL 中的命名占位符（如:status）严格一致 - 位置占位符（
?）在 DQL 中不被支持，只在原生 SQL 中可用；DQL 必须用命名式，如:price
哪些地方最容易漏掉参数绑定
常见高危场景不是写错语法，而是“以为安全”却没绑：
- 动态
ORDER BY字段名：p.. $request->query->get('sort') → 必须白名单校验：in_array($sort, ['name', 'price', 'createdAt'], true) - 动态
IN列表：WHERE p.id IN (:ids)后只调setParameter('ids', [1,2,3])不够，要加类型声明：setParameter('ids', [1,2,3], \Doctrine\DBAL\Types\Types::INTEGER)或Connection::PARAM_INT_ARRAY - 多条件组合时反复调
andWhere()却忘了对每个条件里的变量都设参，例如：->andWhere('p.status = :status')->andWhere('p.type = :type')，但只设了status参数，type没设 → 运行时报错或查不到数据
查单条结果时的异常陷阱
getSingleResult() 看似方便，但它是“强契约”：要么返回一个对象，要么抛异常。生产环境不加 try/catch 就等于主动制造 500 错误。
- 查不到 → 抛
NoResultException - 查到多个 → 抛
NonUniqueResultException - 推荐写法：先加
->setMaxResults(1)显式限流，再捕获异常并返回null，语义清晰且避免意外多查 - 如果只是“可能有一条”，优先用
getOneOrNullResult()，它不抛异常，查不到直接返回null，更符合多数业务逻辑
关联查询必须显式 JOIN + addSelect
DQL 不会自动加载关联属性。写 SELECT p FROM App\Entity\Product p 后，在模板里访问 {{ product.category.name }}，Doctrine 默认触发懒加载——列表页 N+1 查询就此产生。
- 要一次性取回分类名，必须写：
SELECT p, c FROM App\Entity\Product p LEFT JOIN p.category c - 且必须补上
addSelect('c')（在 QueryBuilder 中）或在 DQL 字符串里明确列出c - 别名
c必须与实体中定义的关联属性名一致（如Product::$category），拼错就查不到关联数据 - LEFT JOIN 和 INNER JOIN 语义不同：前者保留无分类的商品，后者只返回有分类的——选错会导致数据丢失
最常被忽略的一点：DQL 的安全边界只到参数绑定为止。字段名、表名、排序方向这些无法参数化的部分，必须靠白名单或类型强转兜底，否则参数绑定再严也没用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
