Go mod 好菜系列 - 0x0A ent 不是 ORM，它更像一套数据层工程化方案

如果说 gorm 是“ORM 老朋友”，sqlx 是“我自己写 SQL 但想省点力气”，那 ent 就是另一条完全不同的路。它不是只想给你一个查库 API，而是试图把数据层从 schema、代码生成、查询到迁移，整成一套更强约束的工程方案。

ent 最核心的气质是什么

是 schema 驱动 + 代码生成 + 类型安全。

也就是说，你不是先写数据库表，再去手动对齐模型；而是先写 ent schema，然后让它生成客户端、查询能力和很多配套代码。

一个 schema 大概长这样

type User struct {
    ent.Schema
}

func (User) Fields() []ent.Field {
    return []ent.Field{
        field.String("name").NotEmpty(),
        field.String("email").Unique(),
    }
}

这和 gorm 那种“结构体上挂 tag”的感觉完全不是一回事。ent 更像是在写一个“数据模型定义文件”。

为什么有人会特别喜欢 ent

• 类型安全感强
• 生成代码以后，IDE 提示体验很好
• schema 和关系表达更明确
• 团队协作时约束感更强

如果一个项目数据模型比较复杂、关系比较多、团队又很在意一致性，ent 的吸引力会特别明显。

关系定义是它的强项之一

func (User) Edges() []ent.Edge {
    return []ent.Edge{
        edge.To("posts", Post.Type),
    }
}

这种写法比很多 ORM 里的关系约定更显式，也更接近“我正在描述模型结构”这件事。

查询为什么很多人觉得很爽

users, err := client.User.
    Query().
    Where(user.NameEQ("Raymond")).
    All(ctx)

ent 的查询表达力是那种比较“IDE 友好”的风格。你会更明显地感觉到自己是在沿着类型系统和生成方法往下走，而不是在自由拼字符串。

那它的代价是什么

代价也很真实：

• 学习成本更高
• 项目初期搭建感更重
• 你得接受代码生成这套工作流
• 对小项目来说，可能显得有点“菜还没上，餐具先摆满桌”

所以 ent 不是不能用在小项目，而是它天然更适合你已经明确想把数据层管得更规整的场景。

ent 和 gorm/sqlx 怎么选

可以非常粗暴地理解：

• 想快点上手、快速做业务，gorm 更常见
• 想自己掌控 SQL，sqlx 很舒服
• 想把数据层做得更强约束、更工程化，ent 很有吸引力

没有绝对标准答案，主要看项目复杂度、团队习惯和你愿意承担哪种成本。

小结

ent 这道菜不算轻，但很有体系感：

• 它更像数据层工程化方案，不只是 ORM
• schema、关系、查询和生成代码是一整套思路
• 特别适合关系复杂、约束强的项目
• 项目很小时，未必是最划算的第一选择

下一篇我们换到一个完全不同维度的模块：wire。从这开始，话题会从“库怎么用”慢慢转向“项目怎么装配”。