automigrate传值（如user{}）会导致静默失效，因必须传结构体指针（&user{}）才能读取gorm标签；它仅安全补全（建表、加字段、扩类型、加索引/外键），不删字段、不改名、不降not null，且无版本、无回滚、不适用于生产环境。
AutoMigrate 传值不传指针导致静默失效
这是最常被忽略的底层机制问题：db.AutoMigrate(User{}) 看似合理，实际什么都不会做——AutoMigrate 必须接收结构体指针才能读取 gorm: 标签。传值会丢失所有字段元信息，且不报错、不提示、不写日志。
- 正确写法永远是
db.AutoMigrate(&User{})，多个模型可合并调用：db.AutoMigrate(&User{}, &Order{}, &UserRole{}) - 若用变量接收结构体再传，务必确认是地址：
u := User{}; db.AutoMigrate(&u)，而非db.AutoMigrate(u) - GORM v1.25+ 提供
db.Migrator().HasTable(&User{})和db.Migrator().HasColumn(&User{}, "email")，上线前应主动验证关键字段是否存在，不能依赖“跑过就等于生效”
外键、中间表和约束默认不生效
AutoMigrate 默认关闭外键支持，且对多对多关系完全无感。哪怕你写了 Roles []Role `gorm:"many2many:user_roles;"`，只要没显式定义 UserRole 结构体并单独迁移，中间表就不会建，外键也不会加。
- 初始化 DB 时必须显式设
DisableForeignKeyConstraintWhenMigrating: false - 外键字段需配完整标签，例如：
CompanyID uint `gorm:"foreignKey:CompanyID"`，仅靠字段名无法触发约束生成 - 多对多中间表（如
UserRole）必须自己定义 struct，并调一次db.AutoMigrate(&UserRole{})，GORM 绝不自动生成 -
gorm:"uniqueIndex"只在索引名首次出现时建索引；若线上已有同名索引但字段不同，它不会校验或覆盖，直接跳过
字段变更行为不可控且不报错
改了 struct 字段类型或标签，AutoMigrate 是否执行 ALTER COLUMN 完全取决于数据库驱动能力 + 你写的标签精度，而不是你的直觉。
-
Age int → Age *int：尝试把列从 NOT NULL 改为可空，MySQL 5.7+ 可行，旧版可能失败，且不提示 -
Name string → Name string `gorm:"size:200"`：MySQL 下可能扩长度，PostgreSQL 直接跳过，SQLite 则重建整张表（大表危险） -
Age int → Age int64：默认不升级类型！必须显式加gorm:"type:bigint"，否则库中仍是 INT，运行时可能溢出或截断 - 删掉 struct 字段后跑
AutoMigrate，对应数据库列照常存在，变成“幽灵字段”，后续SELECT *可能 panic
生产环境锁表、超时、并发冲突全无防护
AutoMigrate 是纯同步阻塞调用，不设超时、不控 ALGORITHM、不管理事务边界，遇到大表 ADD COLUMN 就卡死，连接池耗尽，服务起不来。
- MySQL 8.0 下 ADD COLUMN 默认仍可能全程 LOCK=EXCLUSIVE，而 GORM 不暴露
ALGORITHM=INSTANT或LOCK=NONE参数 - 多个实例同时启动并执行
AutoMigrate，PostgreSQL 会报relation "users" already exists，MySQL 可能因竞争插入 schema_migrations 表失败 - 它没有版本记录、不写状态表、不支持幂等重试，失败后无法判断哪条 DDL 卡住，也无法安全续跑
- 真正要上生产，必须换
golang-migrateCLI：用migrate up前先migrate status，已有库必须migrate force打标记，.up.sql 只放 DDL，绝不塞 INSERT
真正的风险不在功能缺失，而在它太安静——不报错、不提醒、不验证一致性。你改了 struct，它可能什么都没做；你删了字段，它假装看不见；你上线了，问题只在高并发写入或某次 SELECT * 时突然爆发。
