yii框架activerecord的where数组语法（如['username' => $input]）天然防sql注入，因底层使用pdo预处理绑定参数；但字符串拼接、orderby/groupby动态字段、原生sql未绑定等场景极易触发注入，必须白名单校验或严格参数化。
ActiveRecord 查询天然防注入，但别乱用 where 的数组语法
Yii 2 的 User::find()->where(['username' => $input]) 这类写法，默认走 PDO 预处理，$input 不管是 'admin\' OR 1=1--' 还是空字符串，都会被当纯值处理，不会触发 SQL 注入。这是最省心、最推荐的路径。
但注意：如果写成 where('username = "' . $input . '"') 或 where("username = '$input'")，就立刻掉进坑里——字符串拼接绕过了所有防护机制。
常见错误场景：
- 在动态构建条件时，误把用户输入直接拼进 SQL 字符串
- 从旧 PHP 项目迁移代码，保留了
mysql_real_escape_string思维，以为加了转义就安全 - 在
orderBy、groupBy等子句中传入未校验的用户参数（这些不支持参数绑定）
原生 SQL 必须用 bindValue 或命名占位符，别碰 bindParam 的引用陷阱
当你必须写原生 SQL（比如复杂视图、存储过程调用），createCommand() 是唯一入口，但绑定方式决定生死。
正确做法是用命名占位符 + bindValue()：
$sql = 'SELECT * FROM post WHERE status = :status AND created_at > :since';
$posts = Yii::$app->db->createCommand($sql)
->bindValue(':status', $status, \PDO::PARAM_INT)
->bindValue(':since', $dateStr, \PDO::PARAM_STR)
->queryAll();
容易踩的坑：
-
bindParam()是引用传递，如果变量后续被修改，执行时会取最新值，导致结果不可控 - 漏写第三个参数（如
\PDO::PARAM_INT）可能导致类型隐式转换，影响索引或比较逻辑 - 用问号占位符（
?）时，顺序必须严格对应bindValue()调用顺序，易错且难维护
IN 子句里的数组参数不能直接塞，得用 createNamedParameters
用户提交了一组 ID：[101, 205, 333]，想查 WHERE id IN (101, 205, 333)。别手写字符串拼接，也别用 where(['id' => $ids])（它只适用于 ActiveRecord 查询，且底层仍需生成占位符）。
正确解法是让 Yii 帮你生成带序号的占位符：
$ids = [101, 205, 333];
$params = Yii::$app->db->getQueryBuilder()->createNamedParameters($ids);
// 返回 [':qp0' => 101, ':qp1' => 205, ':qp2' => 333]
<p>$sql = 'SELECT * FROM user WHERE id IN (' . implode(', ', array_keys($params)) . ')';
$users = Yii::$app->db->createCommand($sql, $params)->queryAll();
</p>
关键点：
- 手动拼
IN列表（如"'".implode("','", $ids)."'"）等于放弃所有防护 -
Query构建器的andWhere(['id' => $ids])在原生 SQL 场景下不生效，它只作用于 Query 对象 - 数组过大时（如上千 ID），要考虑分批查询或改用临时表，避免 SQL 长度超限或性能骤降
ORDER BY 和 GROUP BY 字段必须白名单校验
这类子句无法参数化——数据库不允许把列名/表名当参数绑定。所以任何来自用户的排序字段（如 $_GET['sort']）都必须显式限制范围。
推荐写法：
$allowedSorts = ['name', 'created_at', 'status', 'price'];
$sort = Yii::$app->request->get('sort', 'created_at');
if (!in_array($sort, $allowedSorts)) {
throw new BadRequestHttpException('Invalid sort field');
}
$posts = Post::find()->orderBy($sort . ' DESC')->all();
为什么不能妥协：
- 用
preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*$/', $sort)校验看似宽松，但可能放行name ASC, id DESC这类组合，破坏预期逻辑 - 前端传
sort=name;DROP TABLE user;，即使正则没拦住，后端拼进去也会执行恶意语句 - 模型规则（
rules()）对orderBy无效，它只校验属性赋值，不干预查询构造
真正危险的不是技术多难，而是开发者误以为“用了 Yii 就万事大吉”，在 orderBy 这种地方随手接用户输入。白名单不是可选项，是强制项。
