优先选eloquent orm处理有明确模型和关联关系的业务对象，如用户、订单；查询构造器适用于复杂联查、统计报表或无模型的一次性操作；二者可混合使用，按语义清晰度与实际需求灵活选择。
选 ORM 还是查询构造器，关键看数据操作的语义是否清晰、模型是否存在、业务逻辑是否需要对象化处理。Eloquent ORM 更适合有明确业务实体和关联关系的场景；查询构造器更适合一次性、条件复杂或无需模型封装的查询。
用 Eloquent ORM 的典型情况
当你操作的是一个真实业务对象（比如用户、订单、文章），且表结构已通过模型定义，就该优先用 ORM：
- 模型间存在标准外键关系（如 Order belongsTo User），用
with()预加载可避免 N+1 查询 - 需要软删除、自动时间戳、属性访问器/修改器、批量赋值保护等内置功能
- 要复用作用域（Scopes）、全局作用域或自定义查询方法
- 后续可能涉及模型事件（
creating、saving）或观察者逻辑
用查询构造器（DB::table）的合适时机
当查询不绑定具体模型，或逻辑太定制化、ORM 不易表达时，查询构造器更直接高效：
- 多表联查条件复杂，涉及非标准关联字段或跨多个无模型对应表
- 只读统计类查询（如分组聚合 + 多层嵌套子查询），写原生 SQL 更清晰
- 临时导出数据、后台报表、迁移脚本中的一次性数据处理
- 性能敏感场景下需精确控制 SELECT 列、避免模型实例化开销
别强行二选一：它们可以共存
实际项目中常混合使用：
- 主流程用 Eloquent 获取模型，再用
DB::table()补充一个统计字段 - 在 Eloquent 模型里用
toBase()获取底层查询构造器，做深度定制 - 复杂报表先用 DB 构建结果集，再用集合方法（
collect()）转成类对象处理
一个快速判断小技巧
问自己三个问题：
- 这个数据要不要被当成「对象」反复调用方法（如
$user->posts）？→ 是 → 用 ORM - 这次查询会不会只执行一次，且结果只是数组或简单统计？→ 是 → 用 DB
- 有没有现成的模型？模型字段和表结构是否一致？→ 否 → 别硬套 ORM，用查询构造器更省事
