为什么国内的微服务框架都不用 gorm 作为微服务框架的 orm？

我一直都用 gorm ，同事也用 gorm

bun 比 gorm 好用很多

这个要问原作者的自己的考量了。

gorm 提供了大量的抽象层和自动化功能，内部使用了不少的反射操作，在处理复杂 SQL 或高并发场景时，性能不够好，在简单查询和标准 CRUD 操作上，grom 通常能够提供足够的性能了。

这个微服务框架默认使用的是 gorm ，也可以使用自己熟悉的 orm 替代 gorm 。
https://github.com/zhufuyi/sponge

可读性吧 ,国内互联网大多是单表查询用不到那些高级玩意

字节都用 gorm 吧 gorm 作者也在字节

最近遇到的 gorm 硬伤：假设一个表有很多字段（数十个），在查询时，对于 A 字段，我要使用函数，例如地理数据：`astext(geometry) AS geometry`，其他字段不变，使用 gorm ，似乎没有 API 实现这个需求，只能手动 select(all_fields...)。

框架作者喜好

可能是把组员的 sql 水平尽量拉到同一水平线上。ent 是完全的 go 代码，增删改查基本不用去写 sql ，直接使用 ent 生成的 go 代码即可

不好用

golang 上的 orm 都不怎么好用..

gorm xorm 都有用

难道没有人用 https://github.com/go-jet/jet 吗？ 非常好用！

@gvison #3 这个好像没有整合依赖注入相关的啊

没有人提 ent 吗？最近正打算试试看，用 gorm 总有一种就是在写原生 sql 的感觉

@zoharSoul 不需要依赖注入也可以在 解耦、测试性、灵活性、可扩展性 满足要求的

@yuzuhi 咋不试试 gorm/gen https://gorm.io/gen/query.html

一般拆成微服务，大多服务不会写复杂的 sql ，毕竟微服务数据库都是拆分很细了，复杂的联表查询自然少，自然要个简单的 orm ， 个人猜测。

目前用的最多的还是 gorm, 也了解过 sqlc （基于 sql 生成代码）

如楼上上上...所说, gorm 作者在字节，经过很多线上场景的考验，所以性能问题不用考虑(字节的体量你懂的），是经过大量优化的，同时 gorm 提供了 基于数据库表生成代码，还支持通过编写复杂 sql 生成代码，非常方便，也可以避免常见的 SQL 注入

很多框架还是用 gorm 的，比如： https://github.com/go-eagle/eagle

@qloog 补充 内部 gorm 和 开源版本基本一致，不同的是内部版本只是更多适配了他们自己的基建

jinzhu 去字节啦? 之前还在 longbridge 的