laravel标准方法如where()、find()等天然防sql注入，因其底层使用pdo预处理将sql结构与数据分离；whereraw()等裸sql接口须手动绑定参数；动态字段名必须白名单校验；启用pdo::attr_emulate_prepares=false可增强安全性。
只要用 Laravel 的 where()、find()、update() 等标准方法，且不手动拼接 SQL 字符串，就基本不会被 SQL 注入——这不是靠“过滤”或“转义”，而是 PDO 预处理在底层把 SQL 结构和数据彻底分离了。
为什么 where() 天然安全？
它不是对输入做字符替换，而是调用 PDO::prepare() 生成带占位符的 SQL 模板（比如 SELECT * FROM users WHERE id = ?），再用 PDOStatement::execute() 单独传值。数据库服务器先编译语句结构，执行时只填数据，恶意字符串连解析机会都没有。
- 所有 Eloquent 和 Query Builder 的常规方法都走这条路，包括
insert()、delete()、orderBy()（但注意：字段名不能是用户输入） - 即使传入
"1' OR '1'='1"这种字符串，PDO 也会把它当纯文本塞进参数，不会改变 SQL 语义 - 底层不依赖
mysql_real_escape_string类似逻辑，所以不惧编码绕过、宽字节等老套路
whereRaw() 和 selectRaw() 怎么用才安全？
这些方法跳过了框架的自动绑定，直接把字符串塞进 SQL，属于“裸 SQL 接口”，必须手动补上参数绑定，否则等于开门揖盗。
- 错误写法：
whereRaw("email = '" . $request->input('email') . "'")—— 用户输入直接拼进 SQL - 正确写法：
whereRaw("email = ?", [$request->input('email')])或whereRaw("email = :email", ['email' => $request->input('email')]) - 如果要动态字段或表名（如按用户选的 category 排序），绝不能用
orderBy($request->input('sort'))，必须走白名单校验：in_array($sort, ['name', 'created_at'], true) ? $sort : 'id'
为什么 ATTR_EMULATE_PREPARES = false 更可靠？
Laravel 默认用 PDO 的模拟预处理（ATTR_EMULATE_PREPARES = true），即 PHP 层自己拼 SQL + 转义；而设为 false 后，真正交由 MySQL 服务端预编译，杜绝客户端层面的解析歧义。
- 多语句注入（如
; DROP TABLE users）在模拟模式下可能绕过，服务端原生预处理会直接报错 - 某些特殊编码组合（如 %A0 后接单引号）在模拟模式下可能被误判，原生模式由 MySQL 引擎统一处理编码上下文
- 修改方式：在
config/database.php的 MySQL 配置里加'options' => [PDO::ATTR_EMULATE_PREPARES => false] - 注意：部分旧版 MySQL（
最危险的不是不懂怎么写 whereRaw()，而是以为 $fillable 或 $casts 能防注入——它们只管属性赋值和类型转换，跟 SQL 构造完全无关。真正关键的防线，始终是“结构与数据是否分离”，而这取决于你有没有让 PDO 去执行那一步 prepare()。
