ThinkPHP 6 的 where 方法默认防 SQL 注入，但手动拼接字符串（如 where("name = '$name'")）会失效；应使用参数绑定形式（如 where('name', $name)），动态字段需白名单校验，原生 SQL 必须用 ? 占位符并顺序绑定，Raw 和闭包查询需严格过滤用户输入，开启 debug 和 trace 可通过日志中的 Params 验证防护是否生效。
ThinkPHP 6 的 where 方法默认已防 SQL 注入，但手动拼接字符串仍会中招
ThinkPHP 6+ 的查询构造器（如 where、select）底层自动使用 PDO 参数绑定，只要你不主动把变量塞进 SQL 字符串里，就基本安全。真正出问题的，是那些看着“方便”实则危险的操作。
常见错误现象：Database query error 报错同时伴随异常 SQL 日志，比如日志里出现 WHERE name = 'admin' OR 1=1 -- ' 这类明显被篡改的语句。
- 别写
$model->where("name = '$name'")->select()—— 单引号包裹 + 变量插值，PDO 绑定完全失效 - 正确写法是
$model->where('name', $name)->select()或$model->where(['name' => $name])->select() - 如果必须动态字段名（如排序字段），先白名单校验：
in_array($sortField, ['id', 'create_time', 'status']) ?: die('非法字段')
手写原生 SQL 时，Db::query 和 Db::execute 必须用问号占位符
用 Db::query() 查数据、Db::execute() 执行增删改时，ThinkPHP 不会自动识别变量位置——它只认问号 ? 占位符，且只支持顺序绑定，不支持命名绑定（如 :name）。
使用场景：复杂子查询、UNION、存储过程调用等无法用查询构造器表达的情况。
立即学习“PHP免费学习笔记（深入）”；
- ✅ 正确：
Db::query("SELECT * FROM user WHERE status = ? AND type = ?", [$status, $type]) - ❌ 错误：
Db::query("SELECT * FROM user WHERE status = $status")—— 直接拼接，零防护 - ⚠️ 注意：
?不支持在表名、字段名、ORDER BY 子句中使用；这些地方只能靠白名单或正则过滤
raw 查询和闭包查询容易绕过绑定，要格外盯紧变量来源
Raw 表达式（Db::raw()）和闭包查询里的 where 是“信任区”，ThinkPHP 默认不干预内容。一旦你把用户输入喂进去，防护就彻底失效。
性能影响不大，但风险极高——这类写法常出现在分页 COUNT、JSON 字段查询、GIS 计算等场景。
- ❌ 危险：
$model->where('extra', 'like', '%' . input('keyword') . '%')->select()——input()未过滤，%通配符又放大危害 - ✅ 安全：
$model->where('extra', 'like', '%' . addslashes(input('keyword')) . '%')不行！addslashes不防 PDO 场景；应改用whereLike：$model->whereLike('extra', input('keyword')) - ? 闭包中也得守规矩：
$model->where(function ($q) use ($keyword) { $q->where('title', 'like', "%{$keyword}%"); })→ 改成$q->where('title', 'like', "%{$keyword}%")依然错！必须用数组或双参数形式
开启 debug 模式时的 SQL 日志是排查注入的第一线索
线上环境关掉 app_debug 后，Database query error 只报通用错误，看不出真实 SQL。但开发/测试环境打开后，日志里会打印每条执行语句和绑定参数，这是验证是否真用了绑定的最直接方式。
容易被忽略的地方：日志里看到 SQL: SELECT * FROM user WHERE id = ? | Params: [123] 才算安全；如果显示 SQL: SELECT * FROM user WHERE id = 123，说明你 somewhere 把变量直接拼进去了。
- 检查路径：
runtime/log/下按日期生成的日志文件，搜索SQL:关键字 - 确认配置：
app.php中'app_debug' => true，且数据库配置'trace' => true - 注意：
trace开启后有轻微性能损耗，切勿在压测或高并发接口中长期开启
事情说清了就结束。真正卡住人的，从来不是“要不要防”，而是哪一行代码悄悄绕过了框架的防护层——多看一眼日志里的 Params，比背十遍文档管用。
