gorm重构遗留系统核心是automigrate+raw sql+model layer isolation三步稳旧逻辑，禁用自动时间戳、软删除、钩子及外键约定，显式映射字段、手动维护约束、慎用save避免upsert误判。
直接上结论：GORM 重构遗留系统数据库操作，核心不是换 ORM，而是用 AutoMigrate + Raw SQL + Model Layer Isolation 三步稳住旧逻辑，再逐步替换。硬切 GORM 模型、盲目启用钩子或强加软删除，90% 的项目会在第 3 天遇到外键失效、时间字段错乱或事务不一致。
为什么不能直接 scaffold 生成模型就开干
遗留系统往往存在：无主键表、复合主键、命名不规范字段（如 user_name_2）、手写触发器、视图混用、甚至 MyISAM 引擎表。GORM 的 scaffold 工具（比如 smallnest/gen）能生成结构，但不会帮你判断 updated_at 是由 DB 触发器维护还是应用层写入——一旦你启用 GORM 的自动时间戳，就可能覆盖掉数据库侧的业务逻辑。
常见错误现象包括：
- 查询返回空，但原 SQL 在客户端能查出数据（原因：GORM 默认忽略
NULL值字段，而 legacy 表大量允许NULL的非空业务字段） -
SELECT * FROM user被 GORM 自动转成带WHERE deleted_at IS NULL（你没显式关掉软删除） - 外键字段名是
owner_id_ref，GORM 按约定找OwnerID，结果关联失败且无报错
正确做法是先禁用所有自动行为：
- 定义 struct 时显式用
gorm:"column:owner_id_ref"映射字段 - 在
db.AutoMigrate(&User{})前，加db.Session(&gorm.Session{SkipDefaultTransaction: true})避免建表干扰 - 禁用全局钩子：
db.Callback().Create().Remove("gorm:assign_current_time")
如何安全过渡：保留旧 DAO，只让 GORM 负责新功能
不要删老代码，也不要重写整个 DAO 层。采用「双读写」策略，让新旧路径并存，靠开关控制流量。
典型结构：
- 老路径：仍走
sqlx.QueryRow或原生database/sql执行关键 SQL（如资金扣减、库存预占） - 新路径：GORM 只用于管理后台、报表导出、非核心查询等容忍延迟/重试的场景
- 共用同一
*gorm.DB实例，但不同业务模块用不同Session隔离事务级别和上下文
示例：给用户中心加一个「最近登录设备列表」接口，不用动原有登录日志表的写入逻辑，只用 GORM 读：
type LoginLog struct {
ID uint `gorm:"primaryKey"`
UserID uint `gorm:"column:user_id"`
Device string `gorm:"column:device_type"`
CreatedAt time.Time
}
// 不启用 AutoMigrate，不加钩子，不设软删除
db.Raw("SELECT * FROM login_log WHERE user_id = ? ORDER BY created_at DESC LIMIT 10", userID).Scan(&logs)
这样既复用 GORM 的 struct 映射能力，又绕过它对 schema 的强假设。
外键、索引、约束怎么处理才不翻车
GORM 的 AutoMigrate 会尝试同步索引和外键，但在遗留库上这是高危操作——它可能删掉 DBA 手动加的唯一组合索引，或把 ON DELETE CASCADE 改成 SET NULL。
必须手动干预：
- 用
db.Migrator().HasIndex(&User{}, "idx_user_status_created")先检查是否存在，再决定是否建 - 外键一律用
db.Exec("ALTER TABLE ... ADD CONSTRAINT ...")原生命令维护，不依赖foreignKeytag - 对含触发器的表，struct 中对应字段加
gorm:":false"禁止读写，只用Raw()操作
特别注意 MySQL 5.7+ 的 ONLY_FULL_GROUP_BY 模式：GORM 生成的 GROUP BY 语句常漏字段，导致查询直接报错。此时必须用 db.Table("xxx").Select("a, b, COUNT(*)").Group("a, b") 显式列出全部分组字段。
最易被忽略的一点：GORM 的 Save() 默认是 UPSERT（有则更新、无则插入），而 legacy 系统里绝大多数更新都是严格 UPDATE ... WHERE id = ?。如果旧数据主键不是自增整数（比如 UUID 字符串），Save() 可能误判为新记录，造成脏数据。永远优先用 FirstOrCreate 或 Where(...).Updates(...) 替代裸 Save。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
