ThinkPHP的validate方法不防SQL注入，仅校验数据格式；真正防护靠查询构造器的参数绑定，手动拼接、whereRaw误用、order/group动态输入等均会绕过防护，须结合白名单与强类型转换。
ThinkPHP 的 validate 方法默认不防 SQL 注入
很多人以为只要用了 validate，数据就“安全了”，其实不是。ThinkPHP 的验证器（Validate 类）只校验格式、长度、规则匹配，它不干涉变量如何被拼进 SQL——哪怕你写了 ['name' => 'require|alphaNum']，如果后续用 where('name', $_POST['name']) 直接拼字符串，照样中招。
真正起防护作用的是查询构造器的参数绑定机制，不是验证器本身。
- 验证器只负责“这值合不合格”，不管“这值怎么用”
-
validate通过后，仍需确保所有数据库操作走预处理（如where()、value()等方法传参，而非字符串拼接） - 自定义验证规则里如果调用了
Db::query()或拼接 SQL，反而会引入新风险
哪些写法会绕过 ThinkPHP 的自动参数绑定
ThinkPHP 在使用查询构造器时默认启用 PDO 预处理，但某些写法会让它退化为字符串拼接，等于关掉防护。
- 用
where('name = "' . input('name') . '"')—— 手动拼接，绑定失效 - 用
whereRaw()且第二个参数没传绑定数组：whereRaw('status = ? AND name = ?', [$status, $name])正确；但whereRaw('status = ' . $status)错误 - 在
order()、group()中直接塞用户输入：order(input('sort'))，这些方法不支持绑定，必须白名单过滤 - 用
Db::execute()执行原生 SQL 时，没用占位符：Db::execute("UPDATE user SET name='" . $name . "'")
验证器 + 查询构造器的安全组合写法
验证只是第一道筛子，关键在“筛完怎么用”。推荐把验证和查询逻辑耦合进同一个流程，避免中间插入手动拼接。
立即学习“PHP免费学习笔记（深入）”；
- 验证通过后，统一用
data()获取过滤后的数据：$data = (new UserValidate())->check($params) ? $params : []; - 查询时全部走键值对传参：
UserModel::where('id', $data['id'])->update(['name' => $data['name']]) - 批量更新/插入也安全：
UserModel::insert($dataList)，框架会自动拆解并绑定 - 需要动态字段名？别从用户输入直接取，用白名单映射：
$allowFields = ['name', 'email', 'status']; $field = in_array($inputField, $allowFields) ? $inputField : 'name';
容易被忽略的「非主键字段」注入点
大家盯紧 id 和 where，但像 order、field、alias 这些方法不走绑定，又常被动态构造，是高危盲区。
-
select($fields)：若$fields = input('fields')，攻击者可传*,(SELECT password FROM user WHERE id=1) -
alias()：传入恶意别名可能干扰 SQL 结构，尤其配合子查询时 -
buildSql()返回的语句如果被日志记录或二次处理，也可能暴露原始未过滤内容 - 分页参数
page和limit虽然数值型，但若没强转成 int，可能触发 MySQL 的类型隐式转换绕过（如传1 union select ...）
这些地方没有银弹，只能靠白名单、强类型转换、拒绝非常规字符三重兜底。框架不会替你决定“这个字段能不能由用户控制”，得自己划清边界。
