应严格校验 orderByRaw 的用户输入，仅允许白名单字段和方向；多表排序需显式指定表名；函数排序会导致索引失效，应建函数索引或冗余字段优化。
orderByRaw 里写 SQL 表达式要防注入
直接拼接用户输入到 orderByRaw 是危险的，Laravel 不会自动转义排序字段里的变量。比如 orderByRaw("name {$request->sort_dir}")，如果 $request->sort_dir 是 ASC; DROP TABLE users，就不是排序问题了。
- 只允许白名单控制方向：用
in_array($dir, ['ASC', 'DESC'])校验，再拼接 - 字段名也得白名单：
['name', 'created_at', 'score']，别用用户传的任意字符串当字段 - 真要动态字段 + 方向，拆成两步：
orderBy($field, $direction)，它比orderByRaw更安全、更直观
Laravel orderByRaw 和原生 ORDER BY 的行为差异
orderByRaw 本质是把字符串原样塞进 SQL 的 ORDER BY 子句，不加反引号，也不做任何字段合法性检查。这意味着你写 orderByRaw('updated_at + 1') 没问题，但写 orderByRaw('user.name') 在多表 JOIN 场景下可能报错——MySQL 不认这个别名，除非你提前定义好表别名或用完整表名。
- 多表查询时，显式写
orderByRaw('users.updated_at DESC')，别依赖隐式别名 - 想按计算值排序（如距离、权重），
orderByRaw是刚需；但简单字段排序，优先用orderBy('column', 'DESC') - 注意 MySQL 严格模式下，
SELECT id, name FROM users ORDER BY updated_at + 1可能触发ONLY_FULL_GROUP_BY报错，Laravel 不会帮你绕过
orderByRaw 配合 withCount 或 join 时的常见错误
在关联统计或联表后排序，容易误以为 withCount('comments') 生成的 comments_count 字段可以直接用于 orderByRaw('comments_count DESC') ——其实不行。Eloquent 默认不会把聚合字段放进 SELECT，除非你显式 select('*','comments_count') 或用 withCount 后手动 addSelect。
- 正确做法：
addSelect(DB::raw('COUNT(comments.id) as comments_count'))→join(...)，再orderByRaw('comments_count DESC') - 用
withCount时，排序只能在内存中做（sortByDesc('comments_count')），性能差，别在大数据量下用 -
orderByRaw中引用子查询别名（如(SELECT COUNT(*) FROM comments WHERE comments.post_id = posts.id) as cnt）必须确保该别名出现在SELECT列表里，否则 MySQL 8.0+ 会报Unknown column 'cnt' in 'order clause'
orderByRaw 性能陷阱：函数索引失效场景
写 orderByRaw('UPPER(name)') 或 orderByRaw('DATE(created_at)') 看似方便，但会让数据库无法使用 name 或 created_at 上的普通索引，排序变全表扫描。尤其在百万级数据时，接口响应直接从 50ms 涨到 2s+。
- 真要按大写排序，建函数索引：
ALTER TABLE users ADD INDEX idx_name_upper ((UPPER(name)))（MySQL 8.0+） - 时间字段按天排序，不如存个
created_date字段并建索引，比每次DATE(created_at)计算快得多 - 测试是否走索引：用
DB::enableQueryLog()+EXPLAIN看执行计划，别凭感觉
