Eloquent 的 DB::raw() 和 selectRaw() 是让 ORM 安全拼接原生 SQL 的机制，关键在参数绑定、防注入与作用域控制；必须用于查询构造器无法表达的场景，如数据库特有函数、字段运算聚合、动态排序（需白名单）、复杂 WHERE 表达式。
直接说结论：Eloquent 的 DB::raw() 和 Model::selectRaw() 不是“绕过 ORM”，而是让 ORM 安全地拼接原生 SQL 片段——关键在绑定参数、避免注入、明确作用域。
什么时候必须用 DB::raw()？
不是“想写 SQL 就用”，而是 Laravel 自带的查询构造器或 Eloquent 方法无法表达逻辑时才介入：
- 需要数据库特有函数，比如 MySQL 的
JSON_EXTRACT()、PostgreSQL 的??（JSONB 存在操作符） - 聚合计算依赖字段运算，如
SUM(price * quantity)，且不能靠withSum()拆解 - ORDER BY 动态字段名（注意：字段名不能来自用户输入，否则必须白名单校验）
- WHERE 条件含复杂 CASE WHEN 或子查询表达式（
whereRaw()更合适）
selectRaw() 和 DB::raw() 用法区别在哪？
核心差异是「作用域」和「自动绑定行为」：
-
selectRaw('COUNT(*) as total, MAX(created_at)')：只影响 SELECT 子句，字段别名可直接用，不参与 WHERE/HAVING 绑定 -
whereRaw('price * ? > ?', [1.1, 100])：只影响 WHERE，支持数组参数绑定（防止注入） -
DB::raw('NOW()')是纯字符串占位符，必须手动放进select()、orderBy()等方法里，不自动绑定 - 错误用法：
where('status', DB::raw("'active'"))—— 这会把引号当字面量传入，实际生成WHERE status = 'active'反而安全；但若写成where('status', DB::raw($userInput))就彻底失控
最常踩的坑：参数绑定失效 + 字段名污染
Raw 表达式一旦混入用户数据，又没走绑定，SQL 注入就坐实了：
- ❌ 错误：
whereRaw("name LIKE '%{$request->search}%'")——$request->search里塞%' OR 1=1 --直接沦陷 - ✅ 正确：
whereRaw("name LIKE ?", ['%' . $request->search . '%']) - ❌ 错误：
orderBy(DB::raw($request->sort))—— 字段名未校验，可能变成ORDER BY id; DROP TABLE users - ✅ 正确：
$allowed = ['id', 'name', 'created_at']; orderBy($request->sort && in_array($request->sort, $allowed) ? $request->sort : 'id') - 注意：
selectRaw()中的别名（如selectRaw('COUNT(*) as cnt')）在后续havingRaw()里不能直接用cnt，得重写表达式或改用子查询
性能与可维护性提醒
Raw 表达式本身不慢，但会让代码脱离 ORM 的缓存、日志、连接复用等机制：
- MySQL 的
GROUP_CONCAT()在selectRaw()里能用，但结果是字符串，Eloquent 不会自动转成数组，得手动explode() - 涉及窗口函数（如
ROW_NUMBER() OVER(...)）时，Laravel 10+ 支持fromSub()构建子查询，比硬写DB::raw()更易测试和复用 - 如果一个模型里频繁出现
selectRaw()+whereRaw()组合，说明业务逻辑可能该抽成数据库视图或专用查询类，而不是堆 raw
真正难的不是写对 DB::raw()，而是判断“这里到底需不需要 raw”——多数时候翻一翻 withCount()、when()、orderByDesc() 的文档，比手写原生快且稳。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
