db::raw 不防sql注入，仅作静态sql结构占位符；所有用户输入必须通过bindings传参或白名单校验，严禁拼接变量。
DB::raw 本身不防注入，它只是把字符串原样塞进 SQL —— 安全与否，完全取决于你往里面塞了什么、怎么塞的。
DB::raw 只能嵌入构建器，不能单独执行
很多人误以为 DB::raw("SELECT * FROM users") 能直接运行，其实它只生成一个 RawExpression 对象，没有任何执行行为。真要查数据，得走 DB::select() 或配合查询构建器（如 whereRaw()、selectRaw()）。
常见错误：
- 写
DB::raw("name = '$request->name'")然后丢给whereRaw()—— 单引号挡不住注入，$request->name是恶意字符串时直接执行任意 SQL - 用
DB::raw()包裹整个语句再试图调用->get()—— 报错，因为构建器不认识这种用法
正确姿势：把 DB::raw() 当作“SQL 结构占位符”，只放函数、运算符、字段别名等静态内容；所有变量值必须通过第二个参数（bindings）传入。
动态值必须走 bindings，不能拼进 raw 字符串
DB::raw() 不支持问号或命名占位符，它不参与 PDO 绑定流程。所以任何用户可控的值，绝不能出现在 DB::raw() 的字符串里。
安全写法示例：
DB::table('users')
->select('id', 'name', DB::raw('COUNT(posts.id) as post_count'))
->leftJoin('posts', 'users.id', '=', 'posts.user_id')
->groupBy('users.id', 'users.name')
->havingRaw('COUNT(posts.id) > ?', [5])
->get();
这里 COUNT(posts.id) > ? 的 ? 在 havingRaw() 中，由构建器自动绑定；而 DB::raw('COUNT(posts.id) as post_count') 里没有变量，纯结构，安全。
容易踩坑的场景：
-
selectRaw("CONCAT(first_name, ' ', {$middle})")→ 改成selectRaw("CONCAT(first_name, ' ', ?)", [$middle]) -
whereRaw("status = '{$status}'")→ 改成whereRaw("status = ?", [$status])或直接用where('status', $status) -
orderByRaw("{$sortField} {$sortDir}")→ 字段名和方向无法绑定，必须白名单校验：in_array($sortField, ['name', 'email']) && in_array($sortDir, ['asc', 'desc'])
表名、列名、函数名等标识符必须白名单校验
参数绑定只对“值”有效，对“标识符”（如列名 ElrA2023、表名 logs_2023）完全无效。一旦拼接不可信输入，就等于敞开 SQL 注入大门。
比如这个写法极其危险：
DB::raw("table3.ElrA{$effectiveYear}")
如果 $effectiveYear 来自 URL 参数且未校验，攻击者传 2023; DROP TABLE users-- 就可能触发注入。
安全替代方案：
- 预定义映射数组：
$columns = [2023 => 'ElrA2023', 2024 => 'ElrA2024']; $column = $columns[$year] ?? throw new InvalidArgumentException(); - 请求验证强制约束：
'year' => 'required|integer|in:2023,2024,2025' - 正则过滤（兜底）：
if (!preg_match('/^\d{4}$/', $year)) { ... }
注意：即使用了 DB::raw("table3.{$column}")，也必须确保 $column 是服务端完全可控的字符串，不能含任何用户输入痕迹。
JSON、日期格式化等复杂值要先处理再 binding
像 MySQL 的 JSON_CONTAINS 或 DATE_FORMAT 函数，常被误用来拼接 JSON 字符串或格式模板。但模板本身是结构，值才是数据 —— 模板写死，值走 binding。
错误写法：
whereRaw("JSON_CONTAINS(meta, '{\"tag\": \"{$tag}\"}')")
正确写法：
whereRaw('JSON_CONTAINS(meta, ?)', [json_encode(['tag' => $tag])])
同理，DATE_FORMAT(created_at, '%Y-%m') 是固定模板，安全；但 DATE_FORMAT(created_at, '{$format}') 就危险，$format 必须白名单校验（如只允许 '%Y-%m'、'%H:%i'）。
另外注意 bindings 数组顺序必须严格匹配 ? 出现顺序，PHP null 会自动转为 SQL NULL，但字符串 'null' 或空数组不会，容易导致逻辑错乱。
最易被忽略的一点：DB::raw() 看似只是“加个括号”，但它彻底绕过了 Laravel 的自动转义机制。只要字符串里混进了未经校验的变量，哪怕只有一处，整条 SQL 就不再可信。
