Laravel默认防SQL注入，因where()等方法自动使用PDO预处理绑定参数；但whereRaw()、表名列名等需白名单校验或手动绑定。
只要不手动拼接用户输入进 SQL 字符串，Laravel 默认就防 SQL 注入。它的安全机制不是“额外加功能”，而是你用对了 where()、update()、insert() 这些方法，底层 PDO 预处理就自动生效。
where()、find()、whereIn() 等标准方法天然安全
这些方法全部走参数绑定，传进去的值不会被当 SQL 解析。哪怕用户输的是 "1 OR 1=1" 或 "admin' -- "，最终生成的 SQL 也是带 ? 占位符的预处理语句，数据库只把它当普通字符串。
-
User::where('email', $request->email)->first()—— 安全 -
DB::table('orders')->whereIn('id', $ids)->delete()——$ids是数组也安全 -
User::where('name', 'like', "%{$search}%")->get()—— 模糊匹配照样绑定，不用自己加引号
whereRaw() 和 selectRaw() 是唯一需要你动手的地方
这两个方法绕过自动绑定，等于把 SQL 构造权交给你。一旦里面混入未过滤的用户输入，立刻中招。
- 错误写法：
whereRaw("email LIKE '%{$_GET['q']}%'")—— 单引号、百分号全被当 SQL 语法执行 - 正确写法一（问号占位）：
whereRaw("email LIKE ?", ['%' . $q . '%']) - 正确写法二（命名绑定）：
whereRaw("email LIKE :pattern", ['pattern' => '%' . $q . '%']) - 更推荐：直接用
where('email', 'like', "%{$q}%")，语义清晰且零风险
表名、列名、排序字段不能参数化，必须白名单校验
占位符 ? 只能绑值（values），不能绑标识符（identifiers）。所以 select($column)、orderBy($field)、DB::table($table) 这类操作，拼进去的变量必须提前验证。
- 危险示例：
DB::table('products')->select("product_varient_{$variant_id}")—— 若$variant_id = "1 FROM users --"，SQL 就变成SELECT product_varient_1 FROM users -- FROM products - 安全做法：用
validate()限定范围，比如'variant_id' => 'required|in:1,2,3'，或运行时in_array($variant_id, [1,2,3], true) - 不要只靠
(int)$variant_id：攻击者传"1; DROP TABLE users; --"强转后还是1，但若后续用于其他上下文（如日志拼接、缓存 key），仍有隐患
DB::select() / DB::update() 等原生查询必须手动绑定
这些方法不走 Query Builder 链式调用，完全依赖你传参方式。没绑定 = 直接裸奔。
- 错误：
DB::select("SELECT * FROM users WHERE id = " . $id) - 正确：
DB::select("SELECT * FROM users WHERE id = ?", [$id]) - 也支持命名绑定：
DB::update("UPDATE users SET status = :status WHERE id = :id", ['status' => 'active', 'id' => $id]) -
$fillable和$casts不参与防注入：$casts = ['price' => 'int']能兜住类型，但不能替代绑定；$fillable只防批量赋值，和 SQL 构造无关
最常被忽略的一点是：动态列名、排序字段、表名这些“非值类”输入，根本不在参数绑定保护范围内。很多人以为用了 whereRaw() 并绑了值就万事大吉，结果在 select($userControlledColumn) 里翻车。白名单不是可选项，是硬性要求。
