MySQL 8以下需设DontSupportRenameColumn:true并显式声明字段类型，GORM才用CHANGE COLUMN替代；PostgreSQL原生支持，SQLite则自动重建表。
MySQL 8 以下版本不支持 RENAME COLUMN，GORM 默认会报错
当你调用 db.Migrator().RenameColumn(&User{}, "name", "full_name") 时，如果 MySQL 版本低于 8.0，GORM 会尝试执行原生 RENAME COLUMN 语句，结果直接报错：Error 1064: You have an error in your SQL syntax。这不是你写错了，是驱动层不兼容。
根本原因是 GORM 的 RenameColumn 行为依赖底层数据库能力，而 MySQL 5.7 及更早版本只支持用 CHANGE COLUMN 或 MODIFY COLUMN 间接实现重命名——GORM 不会自动降级处理，必须显式配置。
-
DontSupportRenameColumn: true必须在mysql.Config{}中启用，否则 GORM 会坚持发RENAME COLUMN - 启用后，GORM 改用
ALTER TABLE ... CHANGE old_col new_col type，但要求你**显式提供字段类型**（比如varchar(255)） - 如果你没定义字段类型（例如结构体里只写了
Name string），GORM 无法推断，迁移会失败
RenameColumn 要求结构体字段类型与数据库列类型严格匹配
GORM 在启用 DontSupportRenameColumn: true 后，会读取旧列的类型，再拼出 CHANGE 语句。但它不会智能“猜”类型——它依赖你模型定义中的 tag 显式声明。
比如你想把数据库里的 user_name 列重命名为 full_name，对应结构体字段必须带完整类型描述：
type User struct {
ID uint `gorm:"primaryKey"`
FullName string `gorm:"column:full_name;type:varchar(255)"`
// 注意：这里不是旧名 user_name，而是新名 full_name；且 type 必须和原列一致
}
- 迁移前，确保旧列实际类型是
VARCHAR(255)，否则CHANGE会因类型不匹配失败 - 如果原列是
TEXT，tag 就得写type:text；如果是TINYINT，就得写type:tinyint - 别依赖
DefaultStringSize，它只影响新建字段，不影响重命名时的类型推导
执行重命名的正确顺序不能颠倒
重命名不是原子操作，GORM 会先 DROP 旧字段、再 ADD 新字段（当 DontSupportRenameColumn: true 时），所以必须保证：
- 结构体中已将字段名更新为新名（如从
UserName改成FullName），且columntag 指向新列名 - 调用
RenameColumn前，数据库里还存在旧列；调用后，旧列消失，新列出现 - 不能一边跑线上服务一边执行——期间读写旧列名的代码会 panic，因为字段已不存在
- 建议在维护窗口期执行，并搭配
db.Migrator().HasColumn(&User{}, "user_name")先校验旧列是否存在
PostgreSQL 和 SQLite 的行为完全不同
如果你换到 PostgreSQL，RenameColumn 默认就能用，不需要设 DontSupportRenameColumn；SQLite 更简单，它压根不支持列重命名，GORM 会自动 fallback 成「建新表 → 导数据 → 删旧表」流程，但要求你开启 DisableForeignKeyConstraintWhenMigrating: true 避免外键报错。
也就是说：同一段 RenameColumn 调用，在不同数据库上走的是完全不同的底层路径。跨库迁移时，别假设行为一致。
最易被忽略的一点：重命名列后，所有使用该列的 SELECT、WHERE、ORDER BY 查询都得同步改结构体字段名或 tag —— GORM 不会帮你做运行时映射修复。
