automigrate不能用于生产环境，因其仅为结构体到表的单向“安全补全器”，不删字段、不改名、不降not null、无版本记录、不支持回滚与幂等，且易因传值非指针、外键未启用等静默失效。
AutoMigrate 为什么不能用在生产环境
它不是迁移工具，只是结构体到表的单向“安全补全器”。你改了 User 结构体字段名、删了字段、把 Age int 改成 Age *int，db.AutoMigrate(&User{}) 什么也不会做——它不删字段、不改名、不降 NOT NULL、不重排顺序，连外键约束都默认关着。
常见静默失败点：
- 传值而非指针：
db.AutoMigrate(User{})→ 完全没反应，也不报错 - 主键没标：
ID uint不加gorm:"primaryKey"，GORM 可能忽略主键或建表失败 - 外键没开开关：初始化 DB 时没设
DisableForeignKeyConstraintWhenMigrating: false，foreignKey标签无效 - 中间表漏掉：
User和Role的多对多关系必须显式定义UserRolestruct 并调AutoMigrate(&UserRole{})
golang-migrate CLI 初始化迁移目录的硬性规则
别直接跑 migrate up，已有线上库会重复建表报错。必须先查状态、再打标记。
正确流程：
- 初始化：
migrate create -ext sql -dir migrations -seq init_schema→ 生成000001_init_schema.up.sql和.down.sql - 序号严禁手改：多实例部署时靠序号排序执行，跳号或乱序会导致部分迁移被跳过
- 已有库必须先
migrate status查当前版本，再migrate force 1把历史状态标记为已执行 -
.up.sql只放 DDL（CREATE TABLE、ADD COLUMN），别塞INSERT初始化数据——那是 seed，得单独管
Go 代码中集成 migrate.Up() 的三个致命坑
直接 migrate.Up() 在生产里等于裸奔：连接失败、SQL 错、锁表超时，全都会 panic，服务起不来。
必须加固：
- 加 context 超时：
m.Up(context.WithTimeout(ctx, 30*time.Second), migrate.All)，避免大表ADD COLUMN卡死无响应 - 区分错误类型：
err == migrate.ErrNoChange是正常（没新迁移），err == migrate.ErrLocked表示被其他实例抢占，别一概log.Fatal - 数据库 URL 必须从环境变量读：
os.Getenv("DB_URL")，禁止硬编码；MySQL 还要确保带?parseTime=true&loc=Local，PostgreSQL 带?sslmode=disable
MySQL 大表迁移时 AutoMigrate 为什么卡住不报错
因为 AutoMigrate 不控制 ALGORITHM 和 LOCK 参数。MySQL 8.0 下 ADD COLUMN 默认仍可能全程锁表，而 GORM 不暴露这些选项，也不设超时，结果就是迁移 hang 住、连接池耗尽、服务不可用。
真正可控的做法：
- 用
golang-migrate写显式 SQL，例如：ALTER TABLE users ADD COLUMN phone VARCHAR(20) ALGORITHM=INPLACE, LOCK=NONE; - 预发环境压测验证锁行为，尤其检查
information_schema.INNODB_TRX是否有长事务阻塞 - 上线前确认 MySQL 版本支持对应 ALGORITHM（如
COPYvsINPLACE），旧版不支持就只能停机窗口操作
最常被忽略的一点：AutoMigrate 没有版本号、不记录状态、无法 down、不审计变更路径——它根本不是给多人协作、多环境部署设计的。拿它上生产，等于把数据库 schema 当成临时草稿本用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
