whereRaw本质是绕过所有安全层的直通通道，直接拼接原始SQL片段，不转义、不绑定、不校验；误用如拼接用户输入会导致SQL注入，正确做法是仅用于可信标识符（需白名单校验）、数值强制类型转换，或改用支持参数绑定的where方法。
whereRaw 本质是绕过所有安全层的“直通通道”
whereRaw() 的设计目标就是让开发者能插入原始 SQL 片段，框架不会对传入字符串做任何转义、绑定或类型检查。它直接拼进最终 SQL 的 WHERE 子句中——这意味着你传什么，数据库就执行什么。哪怕只拼一个用户输入的 input('sort')，只要没白名单校验，'id ASC, (SELECT password FROM user LIMIT 1) 这类 payload 就会原样执行。
常见误用场景：看似可控，实则已失守
这些写法在日志里可能看不出异常，但 SQL 注入已经发生：
-
whereRaw("status = " . input('status'))—— 数字参数不加引号？攻击者传1 OR 1=1直接生效 -
whereRaw("title LIKE '%" . input('q') . "%')—— 单引号被闭合后接UNION SELECT，PDO 绑定完全不介入 -
whereRaw("created_time > '" . input('start') . "'")—— 即使加了单引号，PHP 字符串插值已提前完成，PDO 拿到的是完整拼接串 -
whereRaw("id IN (" . implode(',', input('ids')) . ")")——input('ids')是数组？但implode后仍是裸字符串，无法触发绑定
正确替代方案：按上下文分类处理
不是不能用 whereRaw()，而是必须明确它只适用于「结构固定、来源可信」的片段：
- 字段名、表名、排序方向等标识符 → 必须白名单校验：
in_array(input('order'), ['id', 'name', 'create_time']) ?: 'id' - 数值类条件 → 强制类型转换：
(int)input('limit')，再拼进whereRaw（仅限极少数必须场景） - 模糊查询、范围查询等值操作 → 改用原生支持绑定的接口：
where('title', 'like', '%' . input('q') . '%')或whereBetween('age', [input('min'), input('max')]) - 真需要动态 SQL 片段（如 JSON 查询、GIS 函数）→ 用
whereRaw('json_contains(content, ?)', [$keyword])，显式传参数组触发绑定
容易被忽略的兼容性陷阱
ThinkPHP 6.0–6.2 中 whereRaw() 在闭包查询或链式调用中可能被错误解析；6.3+ 虽增强拦截，但若数据库连接配置中 PDO::ATTR_EMULATE_PREPARES 为 true，即使你写了占位符，底层仍会退化为字符串拼接。验证是否真绑定，得看 MySQL general_log 里出现的是 WHERE id = ? 还是 WHERE id = 123——前者才可信。
立即学习“PHP免费学习笔记（深入）”；
