AutoMigrate只新增字段而不修改类型，因其设计为“安全追加式建模”：仅当字段不存在时才创建，存在则跳过，不执行ALTER COLUMN；类型、长度或约束变更须手动SQL或专用迁移工具。
AutoMigrate 为什么只加字段不改类型
GORM 的 AutoMigrate 不是“同步表结构”，而是“安全追加式建模”：它检测字段是否存在，不存在就新增，存在则跳过——哪怕你把 Name string 改成 Name *string 或加了 size:64 标签，它也不会 ALTER COLUMN。这是设计使然，不是 bug。
常见错误现象：
- 改了结构体字段类型（比如
int→int64），运行AutoMigrate后数据库字段仍是旧类型 - 删了结构体字段，对应数据库列还在，且可能被后续
Create写入 NULL 导致报错 - 加了
uniqueIndex标签但没生效，因为索引名已存在或字段未被识别为变更
正确做法：
- 仅用
AutoMigrate做首次建表或新增字段（如加日志字段、软删除字段） - 字段类型/长度/约束变更，必须手动执行
ALTER TABLE或用迁移工具（如golang-migrate） - 确认变更是否被识别：启动时加
DB.Debug()，看 GORM 是否打印出CREATE INDEX或ADD COLUMN
表名从 users 变成 user 的两种可靠写法
默认复数表名（User → users）在实际项目中常和已有表名冲突，尤其对接遗留库或遵循 RESTful 命名习惯时。改法必须明确且全局生效。
SingularTable: true 是最常用方式，但注意它只影响新注册的模型：
- 配置位置必须在
gorm.Open()的&gorm.Config{}里，不能后设 - 如果多个模型混用（有的要单数、有的要复数），该配置会失效，得换用下一种
更可控的方式是每个模型实现 TableName() 方法：
func (User) TableName() string {
return "user"
}
这种写法优先级高于全局配置，且不会污染其他模型。注意返回值是字符串字面量，不要拼接变量；若需动态前缀（如租户隔离），可结合环境变量或初始化参数生成。
字段映射失败的三个典型标签误用
结构体字段和数据库列名不一致时，靠 gorm: 标签修正。但以下写法极易踩坑：
-
ID uint `gorm:"primaryKey"`：GORM V2 要求显式声明主键，否则可能用id字段但不设自增，导致插入时报错ERROR 1364 (HY000): Field 'id' doesn't have a default value -
Email string `gorm:"column:email_addr"`：column只控制列名映射，不改变类型或约束；若数据库列是VARCHAR(100)，而结构体是string，GORM 不会自动截断，超长时直接报错 -
CreatedAt time.Time `gorm:"autoCreateTime"`：V2 中已废弃，正确写法是CreatedAt time.Time `gorm:"autoCreateTime:milli"`或直接嵌入gorm.Model（含CreatedAt,UpdatedAt,DeletedAt）
验证字段是否映射成功：用 DB.Migrator().ColumnTypes(&User{}) 查看 GORM 解析出的列定义，比肉眼核对更可靠。
生产环境绝对不能依赖 AutoMigrate 自动建表
开发阶段用 AutoMigrate 快速迭代没问题，但上线后它会变成隐患：
- 无回滚机制：一旦新增字段，无法通过代码还原；线上删字段只能手动 SQL
- 并发风险：多个实例同时启动并调用
AutoMigrate，可能触发重复建索引或竞争锁 - 权限限制：生产数据库账号通常禁用
ALTER和CREATE INDEX权限，AutoMigrate直接 panic
真实项目中的做法：
- 所有表结构变更走 DBA 审核的 SQL 脚本，版本化管理（如
V20261101_add_user_score.sql） - 应用启动时只做连接健康检查（
DB.Exec("SELECT 1")），不执行任何 DDL - 若必须代码控制，用
golang-migrate配合up/down脚本，而非依赖 GORM 的迁移逻辑
最易被忽略的一点：即使你写了 AutoMigrate，GORM 也不会帮你创建数据库（CREATE DATABASE），这个动作永远得人工或运维脚本完成。漏掉这步，panic 信息里只会显示“database doesn't exist”，而不是具体哪个环节失败。
