ent generate 不生成代码的主因是 schema 未被正确导入：所有 schema 文件须属 package schema、置于 ent/schema/ 下，且 entc.go 中 entc.Generate 必须显式传入 Schema 选项；图关系需建独立边实体（如 Follow），不能仅靠外键；WithPosts 等方法需配合 Where 等查询条件使用；time.Time 跨库不一致应统一 SchemaType 或改用字符串。
ent generate 命令不生成代码，但没报错
常见现象是执行 ent generate 后目录空空如也，或只生成了 ent/schema 下的 Go 文件，但 ent/client.go 和模型方法全没出现。根本原因不是命令错了，而是 Ent 要求 schema 必须被显式导入到 ent/schema 包里，且该包必须被 entc.gen 引用。
- 确保所有 schema 文件（如
user.go、post.go）都属于package schema，且路径在ent/schema/下 - 检查
ent/entc.go（或你自定义的生成入口）是否调用了entc.Generate并传入了正确的entc.Options{Schema: ./schema} - 如果用的是
ent generate（即 ent CLI），它默认只扫描ent/schema，不会递归进子目录；把 schema 文件直接放在该目录下，别建ent/schema/models/这类嵌套 - 运行前先
go mod tidy，避免因ent依赖版本不一致导致生成器静默跳过
图驱动关系（如 friend_of、follows）怎么写 schema
Ent 本身不提供“图数据库式”的边实体抽象，它的关系模型仍是传统 ORM 的一对多/多对多，但可以通过 Edge + Annotations 模拟有向边语义，比如 “A follows B” 或 “X likes Y”。关键在于：边必须落地为一个独立的实体（Edge 对应一张表），不能只靠两个外键字段存在。
- 为每种边类型建一个 schema，例如
Follow.go，定义FromID和ToID字段，并用edge.From和edge.To显式声明方向 - 不要试图在
Userschema 里用edge.To("followers", User.Type)表达反向关注——这只能建无向关联；真正表达“有向图边”，必须让边自己成为实体 - 如果需要查询“谁关注了 A”，得在
Follow上加索引：index.Fields("to_id")，否则性能会崩 - 注意
edge.From的第一个参数是边名（如"follows"），第二个才是目标 schema 类型，写反会导致生成失败或关系错位
生成后 client 查询嵌套关系时 panic: "field not found"
这是最常踩的坑：你在 schema 里定义了 edge.To("posts", Post.Type)，也跑了 ent generate，但写 client.User.Query().WithPosts().All(ctx) 时却 panic 报 field not found: posts。问题不在 schema，而在查询链路没走通。
-
WithPosts()是生成出来的 *method*，它只存在于*UserQuery类型上，但你必须先调用.QueryPosts()或.QueryXxx()才能触发该方法注册——换句话说，WithPosts不是自动可用的，它依赖于你显式访问过这个 edge - 正确写法是：
client.User.Query().Where(user.ID(id)).WithPosts().Only(ctx)—— 注意必须带Where或其他限制条件，否则Only()会因结果集为空 panic，而All()才是安全的批量取法 - 如果用了
edge.StorageKey自定义外键名（比如改成author_id），生成器不会自动同步更新WithXxx方法的底层逻辑，此时要手动检查生成的ent/user/where.go里字段名是否匹配
MySQL 和 SQLite 下 time.Time 字段行为不一致
Ent 默认把 field.Time 映射为数据库的 DATETIME，但在 SQLite 中它存成字符串（如 "2024-05-12 10:30:45"），MySQL 则是二进制时间戳。这会导致跨库迁移或单元测试时，time.Equal() 比较失败，甚至 Scan 出错。
立即学习“go语言免费学习笔记（深入）”；
- 统一用
field.Time的SchemaType显式指定格式：field.Time("created_at").SchemaType(map[string]string{"mysql": "datetime", "sqlite3": "datetime"}) - 更稳妥的做法是放弃
time.Time，改用field.String存 ISO8601 字符串（"2024-05-12T10:30:45Z"），应用层负责解析，彻底规避驱动差异 - SQLite 驱动（
mattn/go-sqlite3）默认不支持datetime类型的原生扫描，需在 Open DSN 加_loc=UTC&_parse_time=true参数，否则time.Time字段读出来是零值
