AutoMigrate 不可用于线上表结构变更，因其缺乏原子性、回滚、锁控制及超时机制，MySQL 8+下类型不兼容会静默跳过，且并发调用易致死锁或服务挂起。
AutoMigrate 为什么不能直接用于线上表结构变更
AutoMigrate 是开发期的便利工具，不是线上 DDL 方案。它只做结构比对、增量同步，不支持原子性、回滚、锁表控制，且在 MySQL 8+ 严格模式下，字段类型不兼容（比如 int64 对应已有 TINYINT）会静默跳过整张表，既不建索引也不报错。
更关键的是：AutoMigrate 调用期间，如果表被其他请求读写，可能触发死锁或长事务阻塞；而它本身没有超时机制，一旦卡住，整个服务初始化就挂起——这正是“短暂不可用”的直接来源。
- 它不校验连接是否就绪：
db.Migrator().CurrentDatabase()返回空字符串时，AutoMigrate仍会执行并失败静默 - 它不区分新增字段和修改字段：对大表加
NOT NULL字段会锁全表，MySQL 5.7+ 默认阻塞写入 - 它无法控制执行时机：你不能保证所有实例在同一秒内完成迁移，多实例并发调用可能产生竞态
线上表结构变更必须绕开 AutoMigrate
生产环境该用 gh-ost、pt-online-schema-change 或云厂商提供的在线 DDL 工具，而不是靠 GORM 启动时自动跑一遍 AutoMigrate。
GORM 的角色应降级为“适配层”：等 DBA 或运维完成 DDL 后，再通过代码适配新结构。例如：
- 新增字段先以
sql.NullString或指针类型（如*string）定义，避免非空约束导致 scan 失败 - 废弃字段保留 struct 字段但加
gorm:"-"标签，防止 GORM 尝试映射 - 字段重命名用
gorm:"column:old_name"过渡，等数据迁移完毕再切回新名
重点：所有变更必须提前在测试库用真实数据量验证，包括 SELECT 和 UPDATE 性能回归。
如何让服务在 DDL 期间保持可用
核心是解耦“数据库结构变更”和“服务启动/重启”。不能把 AutoMigrate 放在 main() 初始化链里，尤其不能放在 HTTP server 启动之后。
- 禁用启动时自动迁移：设置
SkipDefaultTransaction: true并移除所有AutoMigrate调用 - 用健康检查探针暴露迁移状态：比如
/health?with=db返回{"db": "migrated", "version": "20260819_v2"}，由运维确认后再切流量 - 对读写分离架构，可先在从库执行 DDL，验证无误后主库再执行，中间用
SHOW SLAVE STATUS确保同步延迟归零
如果你真需要代码侧兜底，只允许在灰度发布阶段用带超时的单次迁移：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
if err := db.WithContext(ctx).Migrator().AutoMigrate(&User{}); err != nil {
log.Warn("Migration failed, proceeding anyway: ", err)
}
最容易被忽略的兼容细节
不是所有字段变更都显眼。以下三点在上线前必须人工核对：
- MySQL 的
TIMESTAMP默认值是CURRENT_TIMESTAMP，但 GORM 的time.Time零值是0001-01-01，插入时若未显式赋值，会因 NOT NULL 冲突失败 - PostgreSQL 的
jsonb字段，GORM v2 默认映射为map[string]interface{}，但旧数据可能是 string 类型，scan 时 panic - SQLite 不支持
ALTER COLUMN，AutoMigrate会删表重建，导致数据丢失——这在本地调试时不会暴露，但上生产就是事故
真正可靠的上线节奏是：DDL 工具执行 → 应用灰度重启（不带迁移）→ 观察日志与监控 → 全量切流。别让 ORM 替你做数据库的事。
