Golang Go语言中为什么国内的微服务框架都不用gorm作为微服务框架的orm？
如题，同问，观察了一下，go-zero 用的是自己封装的 sqlx ，还可以理解是最简化，但是完全没好到哪儿去，复杂 sql 很麻烦，kratos 直接用了国外的 Ent ，其他的几个没接触过，想知道这样的考量是什么？
Golang Go语言中为什么国内的微服务框架都不用gorm作为微服务框架的orm？
我一直都用 gorm ，同事也用 gorm
更多关于Golang Go语言中为什么国内的微服务框架都不用gorm作为微服务框架的orm？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
这个要问原作者的自己的考量了。
gorm 提供了大量的抽象层和自动化功能，内部使用了不少的反射操作，在处理复杂 SQL 或高并发场景时，性能不够好，在简单查询和标准 CRUD 操作上，grom 通常能够提供足够的性能了。
这个微服务框架默认使用的是 gorm ，也可以使用自己熟悉的 orm 替代 gorm 。
https://github.com/zhufuyi/sponge
最近遇到的 gorm 硬伤：假设一个表有很多字段（数十个），在查询时，对于 A 字段，我要使用函数，例如地理数据：astext(geometry) AS geometry，其他字段不变，使用 gorm ，似乎没有 API 实现这个需求，只能手动 select(all_fields…)。
目前用的最多的还是 gorm, 也了解过 sqlc （基于 sql 生成代码）
如楼上上上…所说, gorm 作者在字节，经过很多线上场景的考验，所以性能问题不用考虑(字节的体量你懂的），是经过大量优化的，同时 gorm 提供了 基于数据库表生成代码，还支持通过编写复杂 sql 生成代码，非常方便，也可以避免常见的 SQL 注入
很多框架还是用 gorm 的，比如： https://github.com/go-eagle/eagle
作为IT领域Go语言方面的专家，对于Golang中微服务框架的选择与搭配有深入了解。针对国内微服务框架不常选用GORM作为ORM（对象关系映射）工具的问题，以下提供几点专业分析：
- 性能考量：尽管GORM功能强大且易于使用，但在高并发场景下，其性能可能不如一些更为轻量级的ORM框架或原生SQL查询。微服务架构往往对性能有较高要求，因此开发者在选择ORM时会更加谨慎。
- 灵活性需求：微服务架构强调服务的自治和灵活性。在一些场景下，开发者可能需要更直接地操作数据库，以实现特定的业务逻辑或性能优化。GORM虽然提供了丰富的功能，但也可能在某些方面限制了开发的灵活性。
- 生态与习惯：国内开发者在选择微服务框架和ORM时，也会受到技术生态和团队习惯的影响。一些团队可能更倾向于使用经过大量实践验证的框架和工具，或者选择更符合团队技术栈的ORM工具。
综上所述，国内微服务框架不常选用GORM作为ORM工具的原因可能涉及性能、灵活性以及技术生态和团队习惯等多个方面。当然，这并不意味着GORM不是一个优秀的ORM框架，只是在不同场景下有不同的选择。
