大型项目中GORM需结构化约束：用常量或标签生成Preload路径、显式事务管理、模型集中定义、字段标签规范、日志监控与索引校验，避免字符串硬编码、隐式事务和模型分散导致的线上隐患。
大型项目里直接用 GORM 的链式调用 + 字符串预加载（如 Preload("Posts")）会埋下运行时隐患，类型不安全、重构易错、IDE 无法跳转。必须提前做结构化约束，而不是靠“写对字符串”来保证正确性。
避免 Preload 字符串硬编码
硬写 "Posts" 这类字段名是大型项目中最常见的线上 Bug 来源：拼错、改名后漏更新、嵌套层级深时路径写错（比如 "Profile.Address.City"），GORM 都不会报错，只静默失败。
- 用常量封装关联字段名，例如：
const UserPosts = "Posts"，所有Preload统一引用该常量 - 更进一步，用结构体标签自动生成 preload 路径：给
User结构体加gorm:"foreignKey:UserID"，再配合自定义函数生成合法路径列表，供Preload循环调用 - 禁止在业务逻辑里直接写多层字符串路径；超过两层嵌套（如
Preload("Orders.Items.Product")）应拆分为多个独立查询 + 内存关联
事务控制必须显式管理
GORM 的 Transaction 不是自动的，db.Create() 或 db.Save() 单独调用都在默认事务外执行，看似成功，实则无法回滚。尤其在 Service 层组合多个操作时，极易出现数据不一致。
- 事务入口必须明确：用
db.Transaction(func(tx *gorm.DB) error { ... })包裹全部操作 - 不要在事务函数内直接用全局
DB变量，必须使用传入的tx实例，否则脱离事务上下文 - 嵌套调用时禁止传递
*gorm.DB值类型（如func doSomething(db gorm.DB)），指针类型*gorm.DB才能确保事务传播 - 长事务要设超时，避免锁表：在
gorm.Config中配置PrepareStmt: true并结合数据库层 timeout 设置
模型定义必须收敛到统一包
不同模块各自定义同名结构体（如都叫 User），哪怕字段一样，GORM 也会当成不同模型处理——迁移建表重复、预加载失效、钩子不触发。大型项目中模型分散是隐性耦合的温床。
- 所有
struct定义集中放在model/包，导出名带业务前缀（如AuthUser,PayOrder），避免重名 - 禁用
gorm.Model自带的ID/CreatedAt等字段，显式声明并加gorm:"primaryKey"等标签，便于审计和跨库兼容 - 字段标签统一规范：时间字段强制用
type time.Time+gorm:"type:datetime"，避免 SQLite 和 PostgreSQL 解析差异 - 敏感字段（如密码）必须加
gorm:"-"排除，不能依赖上层过滤——GORM 会默认 SELECT 所有非忽略字段
日志与性能监控不可省略
生产环境关掉 LogMode(true) 很容易，但关掉之后就失去了慢查询、N+1 加载、未索引 WHERE 条件等关键线索。大型项目里数据库问题往往不是“崩了”，而是“慢得难以定位”。
- 用
logger.New替代LogMode，设置log.Info级别输出 SQL + 参数 + 耗时，但过滤掉健康检查类的高频短查询 - 在
AfterFind钩子里打点，统计单次请求中 DB 查询次数，超阈值（如 >5 次）主动记录告警 - 对
SELECT COUNT(*)类聚合查询，强制要求加WithContext(ctx).Session(&gorm.Session{DryRun: true})预检执行计划，避免全表扫描 - 所有
WHERE条件字段，必须在模型标签里声明gorm:"index"或gorm:"uniqueIndex"，CI 流程中跑db.Migrator().HasIndex(&model.User{}, "email")校验
真正难的不是写出能跑的 GORM 代码，而是在多人协作、持续迭代中让每一行 db.Preload、每一个 tx.Create 都可追溯、可验证、可替换。字符串、全局变量、隐式事务——这些“方便”的设计，在规模上来后都会变成最顽固的技术债。
