用好参数绑定可基本防住sql注入，因其通过doctrine orm和pdo预处理机制实现数据与sql结构分离；需避免字符串拼接、动态构造查询等错误，并对无法参数化的语法要素采用白名单和类型强转兜底。
用好参数绑定，SQL注入基本防得住。Symfony本身不直接处理SQL，真正起防护作用的是它底层依赖的Doctrine ORM和PDO层的预处理机制。关键不在“怎么写Symfony代码”，而在于“是否让数据和SQL结构彻底分离”。
参数绑定是默认安全的起点
Doctrine查询构建器、DQL、原生SQL执行都强制支持参数化。只要不手动拼接字符串，就天然隔离了注入风险。
- DQL中用
:name或?1占位，再调setParameter()传值 - Query Builder中用
$qb->where('u.email = :email')，然后->setParameter('email', $input) - 原生SQL必须配合
executeStatement()或executeQuery()+setParameters()，不能用executeStatement($sql)直接传拼好的字符串
别绕过参数绑定的几种常见错误
安全防线往往毁在“图省事”的瞬间。这些写法看似方便，实则打开注入大门：
- 把用户输入直接插进DQL字符串：
"u.status = '" . $request->query->get('status') . "'" - 用
sprintf()或str_replace()动态构造WHERE条件 - 从路由、查询参数、表单里取值后，未经验证就用于
IN子句或ORDER BY字段名（这些无法用参数绑定） - 禁用PDO模拟预处理却没确认驱动支持真实预处理：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false)需搭配MySQLi或现代PDO驱动
非参数化位置的安全补救
像表名、字段名、排序方向、IN列表长度这类语法要素，数据库不接受参数占位。必须靠白名单+类型强转兜底：
-
字段名/表名：只允许来自预定义数组，例如
$allowedFields = ['name', 'email', 'createdAt'];，再用in_array($input, $allowedFields, true) -
排序方向：
$dir = strtolower($request->query->get('dir', 'asc')) === 'desc' ? 'DESC' : 'ASC'; -
IN列表：先用
array_map('intval', $ids)转整型，再用implode(',', $ids)拼接，或交给Doctrine的setParameter('ids', $ids, Connection::PARAM_INT_ARRAY)
配合其他层加固更稳妥
参数绑定是核心，但不是唯一防线：
- 数据库连接账号用最小权限原则，禁用
DROP、CREATE、LOAD_FILE等高危权限 - 开启Doctrine的SQL Logger仅限开发环境，生产环境关闭详细错误输出，避免泄露表结构
- 对路由参数做约束，比如
{id}正则限制必须是数字，从入口就过滤非法字符 - 结合Symfony Validator组件，在Form或Request中对字段加
@Assert\Type("string")、@Assert\Length(max=255)等规则
