gorm的automigrate不适合生产环境，因其仅安全补全表结构（建表、加字段、扩类型、加索引/外键），不删字段、不改名、不降not null、不重排、不控制ddl锁行为；应改用golang-migrate等版本化工具，配合显式sql、上下文超时、幂等校验与预发压测。
别用 AutoMigrate 上生产，也别手写 SQL 塞进 main() 里跑 —— 这两种方式在真实业务迭代中都会出事。
为什么 GORM 的 AutoMigrate 不适合线上表结构变更
它只做“安全补全”：建表、加字段、扩类型、加索引/外键；但删字段、改字段名、降级 NOT NULL、重排列顺序，一律不碰。你以为改了 struct 就能同步？错 —— 它根本不会执行这些破坏性操作。
- 必须传结构体指针：
db.AutoMigrate(&User{})，传User{}会静默失败 - 字段标签（如
gorm:"size:200"）必须显式声明，否则类型推导可能出错 - 外键和中间表需手动开启开关：
db.AutoMigrate(&User{}, &Post{}, &UserPost{})，漏一个就丢约束 - MySQL 8.0 下
ADD COLUMN默认仍可能锁表，AutoMigrate不控制ALGORITHM和LOCK参数，大表迁移卡住不报错
用 migrate CLI 管理迁移文件的硬性规则
迁移不是“改完代码就上线”，而是从一个明确版本起点开始。已有线上库不先 migrate status + migrate force，直接跑 migrate up 会重复建表报错。
- 初始化迁移目录：
migrate create -ext sql -dir migrations -seq init_schema，生成000001_init_schema.up.sql和.down.sql - 序号（如
000001）由工具自增，禁止手动修改，否则多实例部署时执行顺序错乱 -
.up.sql只放 DDL（CREATE TABLE、ADD COLUMN），不要塞INSERT初始化数据 —— 那是 seed，该单独管理 - 已有线上库：先
migrate status查当前版本，再migrate force 1把历史状态标记为已执行，避免重复执行
Go 项目里集成 migrate 库时怎么防 panic
直接调 migrate.Up() 在连接失败、SQL 语法错、MySQL 锁表超时时会 panic，而生产环境需要可观察、可中断的失败路径。
- 用
context.WithTimeout(ctx, 30*time.Second)包裹迁移调用，例如：m.Up(context.WithTimeout(ctx, 30*time.Second), migrate.All) - 区分错误类型：
err == migrate.ErrNoChange（无新迁移）、err == migrate.ErrLocked（被其他实例抢占锁），别一概log.Fatal -
migrate.New的数据库 URL 必须从环境变量读取，如os.Getenv("DB_URL")，禁止硬编码 - MySQL 不支持事务性 DDL，
ALTER TABLE失败时整个up过程无法回滚，.down.sql不会自动触发 —— 得靠人工干预
MySQL 上 ADD COLUMN 卡住却不报错的真实原因
这不是 Go 框架的问题，是 MySQL 5.6+ 在线 DDL 的固有限制：当字段加在中间位置、或表行数超百万时，即使启用了 ALGORITHM=INPLACE，仍可能隐式锁表，migrate 会一直等直到上下文超时。
- 优先用
AFTER指定位置：ALTER TABLE users ADD COLUMN status TINYINT DEFAULT 0 AFTER id，避免物理重排 - 确认 MySQL 版本是否真正支持：
5.6仅部分支持，5.7+更完善，8.0对ADD COLUMN基本无锁 -
migrate默认不传ALGORITHM和LOCK，必须在 SQL 脚本里显式写：ALTER TABLE users ADD COLUMN status TINYINT DEFAULT 0, ALGORITHM=INPLACE, LOCK=NONE; - 本地小表测试通过 ≠ 线上可用 —— 预发环境必须用真实数据量压测单条迁移耗时
最常被忽略的一点：迁移脚本的幂等性不等于安全性。哪怕语句本身可重入，DDL 执行期间的锁行为、复制延迟、主从切换都可能让结果不可控 —— 别指望自动化工具兜底所有边界。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
