GORM模型层应独立于业务逻辑，置于internal/models包中仅定义结构体、标签及TableName()方法；gormgen适合CI/CD静态建模，gen库适用于运行时动态定制生成。
直接说结论：GORM 模型层不该混在业务逻辑里，生成工具选 gormgen（CLI）还是 gen（Go 库）取决于你是否需要运行时动态控制——前者适合 CI/CD 和一次性建模，后者适合需按条件生成、注入方法或集成进构建流程的项目。
模型该放在哪一层？别放 internal/service 或 handlers
常见错误是把 User 结构体直接写在 handler 或 service 文件里，导致模型被业务逻辑污染、复用困难、迁移和测试成本飙升。
正确组织方式是单独划出 models 包（如 internal/models），且只做三件事：
- 定义结构体 +
gorm标签（primaryKey、column、foreignKey等） - 实现
TableName()方法（避免复数表名或加前缀） - 可选：加
BeforeCreate等钩子，但仅限与数据持久化强相关的逻辑
不要在 models 里调用 service、访问 cache、拼接 HTTP URL —— 那是 service 层的事。模型就该是“数据库行”的干净映射。
gormgen CLI 工具：适合快速初始化和标准化建模
它本质是命令行程序，执行一次就吐出所有模型文件，不参与编译，也不依赖 Go runtime。适合团队统一建模规范、CI 流水线自动生成、或老项目逆向建模。
典型使用场景和注意点：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 连接串里必须带
parseTime=True和loc=Local，否则time.Time字段会解析失败，报错类似unsupported Scan, storing driver.Value type []uint8 into type *time.Time - 默认生成复数表名（
users→Users），若库中是单数表名（如user），得加参数--singular - 生成的字段名是蛇形转驼峰，但不会处理缩写（
user_id→UserID是对的，api_key→ApiKey也是对的；但http_url会变成HttpUrl，不是HTTPUrl，需手动微调） - 不支持为不同表指定不同 Go 类型（比如想把所有
tinyint(1)映射成bool），得靠后续脚本或人工替换
命令示例：gormgen --dsn="root:pass@tcp(localhost:3306)/mydb?charset=utf8mb4&parseTime=True&loc=Local" --out=./internal/models --singular
gen 库（gorm.io/gen）：适合需要定制化生成逻辑的项目
它是在 Go 代码里调用的库，能拿到 *gorm.DB 实例，因此可以做运行时判断：比如跳过某些系统表、按注释标签过滤、给特定表加软删除字段、甚至注入模板方法。
关键差异和易踩坑点：
-
gen.FieldType("id", "int64")只影响单个字段，但如果你改了主键类型，记得同步检查AutoMigrate是否兼容（比如原库id是INT UNSIGNED，你硬设成int64，迁移时可能报错） -
gen.WithMethod()注入的方法，接收者必须是值类型或指针类型一致；如果结构体字段含*string，而你注入的方法接收者是*User，那没问题；但若方法里用了u.Name != nil判断，就得确保生成时没漏掉非空约束 - 它默认不生成
CreatedAt/UpdatedAt字段，即使表里有对应列——得显式用gen.FieldNew("created_at", gen.FieldType("time.Time"), gen.FieldTag("gorm", "autoCreateTime"))补上 - 生成目标路径（
OutPath）必须是已存在的目录，且不能是go.mod根目录（会冲突），建议固定为./query或./gen
简短示例片段：g.GenerateModel("users", gen.FieldType("status", "UserStatus"), gen.WithMethod(userMethods))
生成后别忘了验证和隔离
生成只是起点，不是终点。最容易被忽略的是两件事：
- 生成的模型没做
Valid()或Validate()方法，导致上游传入非法数据时，错误直到写入数据库才暴露（比如邮箱格式不对、手机号超长）——建议在models包里补充Validate() error方法，用go-playground/validator等校验库绑定 - 生成的代码和手写的业务逻辑混在一个包里，Git diff 里全是“模型字段增减”，掩盖了真正重要的业务变更——强烈建议把生成的模型文件（如
user.gen.go）和手写的扩展文件（如user.go）分开，后者用//go:generate注释标记，CI 可自动识别并拒绝提交生成文件的修改
