Ent 被选用因其代码生成、类型安全、SQL 可控及无 N+1 问题；需手动注入 *ent.Client 到 Gin Context，迁移须在 router.Run 前完成，schema 修改后须重新 go generate。
为什么不用 GORM 而选 Ent？
Ent 不是“更高级的 GORM”，而是设计哲学不同的 ORM：它用代码生成代替运行时反射，类型安全强、SQL 可控、关联查询无 N+1 隐患。你在 ent.Init 之后生成的 ent.Client 是纯结构体+方法，没有全局状态，天然适合 Gin 的 Context 生命周期管理。而 GORM 的 db *gorm.DB 是带连接池和配置的实例，容易在中间件里误传或泄露。
初始化 Ent Client 并注入 Gin Context
Ent 不提供开箱即用的 “DB middleware”，必须手动把 *ent.Client 塞进 Gin 的 Context 或通过依赖注入容器传递。推荐前者，轻量且可控：
- 在
main.go初始化 client：client, err := ent.Open("mysql", "root:pass@tcp(127.0.0.1:3306)/test?parseTime=true")，记得 deferclient.Close() - 写一个中间件：
func EntMiddleware(client *ent.Client) gin.HandlerFunc { return func(c *gin.Context) { c.Set("ent", client); c.Next() } } - 使用：
r.Use(EntMiddleware(client))，后续 handler 里用c.MustGet("ent").(*ent.Client)取出
别直接把 *ent.Client 作为全局变量暴露——它不是线程安全的（虽底层连接池是），但 schema 操作（如 migration）可能并发冲突；也别在每个 handler 里重复 ent.Open，那会新建连接池，资源泄漏。
路由 handler 中调用 Ent 查询的典型写法
Ent 的链式 Builder 语法看着像 SQL，但实际是构建 AST，最终才生成并执行 SQL。这意味着你不能像 GORM 那样靠 db.Where(...).Find(&v) 一行搞定，必须显式调用 .Query() 或 .All() 等终态方法：
- 查单条：
user, err := c.MustGet("ent").(*ent.Client).Users().Where(user.Username("alice")).Only(c.Request.Context()) - 查列表：
users, err := c.MustGet("ent").(*ent.Client).Users().Where(user.HasPosts()).All(c.Request.Context()) - 注意必须传
c.Request.Context()，否则超时、取消信号不生效；Ent 默认不继承 Gin 的 Context，得手动传 - 别漏
err != nil判断——Ent 的Only()在没找到时返回ent.ErrNotFound，不是 nil
Ent 迁移与 Gin 启动顺序怎么协调？
Ent 的 migrate.Run 是同步阻塞操作，必须在 Gin router.Run() 之前完成，且不能放在 handler 里。常见错误是把它塞进中间件或路由函数，导致每次请求都重跑 migration，或者 panic 报 “table already exists”：
- 正确位置：
main()函数最开头，ent.Open()之后、gin.Default()之前 - 示例：
if err := migrate.Create(context.Background(), client); err != nil { log.Fatal(err) } - 生产环境建议关掉自动迁移：
migrate.WithForeignKeys(false)，改用 Flyway 或手动 SQL 管理 schema 变更 - 开发环境可保留，但加个开关：
if os.Getenv("ENV") == "dev" { ... }
Ent 的 schema 定义是 Go 代码，不是 YAML 或 JSON，所以修改字段后必须重新 go generate ./ent，这个步骤容易被忽略，一跑就 panic “field XXX not found”。
