后端数据库交互场景下Query Builder与ORM的区别及选型疑问

很多人觉得这俩写的代码看起来差不多，根本原因是成熟ORM的内部本来就封装了Query Builder，但两者的设计目标、抽象边界完全不一样：

• Query Builder本质是SQL的安全语法糖，核心目标是解决手动拼接原生SQL的痛点：比如帮你做参数转义防SQL注入、自动适配不同数据库的方言差异、简化where/join等条件的链式书写。它的抽象完全没有脱离SQL本身的逻辑——你写的每一句查询，最终都会生成可直接查看、可随意修改的标准SQL，你对最终执行的数据库逻辑有完全的掌控权，比如你写db.table('user').where('age', '>', 18).get()，它内部就是帮你拼出select * from user where age > 18直接发给数据库执行。
• ORM的抽象层级要高得多，核心目标是把数据库表映射为编程语言内的实体对象，让你像操作内存中的对象集合一样操作持久化数据。它不要求你牢记SQL的执行细节、表结构映射规则、关联关系的join逻辑——比如你定义一个User类对应数据库的user表，查询返回的结果直接是User类的实例，实例本身可以挂载业务方法、自动处理字段类型转换（比如把数据库存的时间戳转成编程语言的时间对象、把数字型枚举转成自定义枚举类型），你定义好的一对多、多对多关联关系，它会自动帮你完成连表查询、数据映射、甚至懒加载/预加载的逻辑。

举个直观的写法差异：

# Query Builder 写法，返回的是裸的数组行数据
$users = DB::table('user')
    ->where('age', '>', 18)
    ->get()

# ORM 写法，最终生成的SQL和上面几乎一样，但返回的是带方法、带关联属性的User实体对象
$users = User::where('age', '>', 18)
    ->get()

这个问题本质是没搞清楚：Query Builder解决的是「写SQL不麻烦」的问题，但实际开发里，写SQL不麻烦只是占比20%的痛点，剩下80%的重复劳动，是Query Builder根本覆盖不到的：

• 首先是极致压缩重复样板代码的工作量：通用业务系统里80%的逻辑都是CRUD——如果全用Query Builder写，你每次查完数据都要手动把返回的行数据转成自定义实体、手动处理关联表的字段映射、重复写一堆固定的where条件（比如软删除过滤、租户隔离过滤），写三五次还好，写几百次的时候，重复代码能堆到你改个字段名要全局搜半小时。ORM把这些固定流程全部自动化了，同样的CRUD逻辑，ORM的代码量通常能比纯Query Builder写的少60%以上，业务迭代速度的差距非常明显。
• 其次是实现业务逻辑的高内聚：ORM的实体本身就是业务逻辑的天然载体，你可以在User类里直接封装getFullName()、canSubmitOrder()这类通用业务方法，所有用到用户实体的地方都能直接调用。如果用纯Query Builder写，这些通用逻辑只能散在各个接口的调用代码里，哪天要调整逻辑，得把所有写过用户查询的地方全部找出来改，漏一个就是线上bug。
• 最后是做全局统一管控的成本极低：比如你要给所有用户表的查询加上软删除过滤条件、给所有操作加上审计日志、给多租户系统自动加租户ID的过滤逻辑，用Query Builder的话，你得在每一个查询调用点手动加规则，漏一个就会出现越权查数据的安全问题；但在ORM里，你只要在实体的全局作用域里加一次规则，所有涉及这个实体的查询都会自动带上对应逻辑，根本不会出现漏加的情况。

当然要明确一点：ORM从来不是为了替代Query Builder存在的。对于复杂的多表聚合、性能敏感的极端优化查询，开发者随时可以下切到ORM内部封装的Query Builder层面，甚至直接写原生SQL。两者是互补关系，不是对立关系——ORM的价值就是帮开发者把80%高重复度的通用CRUD活干完，让大家把精力花在真正的业务逻辑上，而不是天天写重复的SQL、写重复的对象转换代码。

内容的提问来源于stack exchange，提问作者M1ask