看起来你遇到的大表迁移导致服务中断的问题非常典型，你的零停机迁移思路方向完全正确。针对你提出的两个需求方向，我给你具体的可落地实现方案：

方案b：复用User结构体，让AutoMigrate仅操作user_temp表（更推荐） #

其实Gorm本身就支持临时覆盖结构体对应的表名，完全不需要额外定义UserTemp结构体。这里有两种稳妥的实现方式：

方式1：使用Scope临时指定表名 #

这种方式不会影响全局的结构体表名映射，只作用于当前的迁移操作，非常安全：

// 这是你已经更新好的User结构体（包含新增/修改的字段）
type User struct {
    ID        uint   `gorm:"primaryKey"`
    Username  string `gorm:"size:50;unique"`
    NewBio    string `gorm:"type:text"` // 新增的字段
    // ... 其他原有字段
}

// 通过Scope临时将表名指定为user_temp，然后执行AutoMigrate
err := db.Scopes(func(tx *gorm.DB) *gorm.DB {
    return tx.Table("user_temp")
}).AutoMigrate(&User{}).Error
if err != nil {
    // 处理迁移错误
    panic(err)
}

执行这段代码时，Gorm会用你更新后的User结构体的结构，去迁移user_temp表，完全不会触碰原有的user表。

方式2：临时替换结构体的TableName方法 #

如果你的User结构体原本就实现了TableName方法，也可以临时替换它的返回值，不过这种方式要注意并发场景（因为全局方法是共享的）：

// 先保存原有的表名
originalUserTableName := new(User).TableName()

// 重新定义User结构体的TableName方法，临时指向user_temp
func (User) TableName() string {
    return "user_temp"
}

// 执行迁移
err := db.AutoMigrate(&User{}).Error
if err != nil {
    // 错误处理
}

// 恢复原有的TableName方法
func (User) TableName() string {
    return originalUserTableName
}

这种方式适合单线程的迁移脚本场景，不建议在服务运行时的并发环境中使用。

方案a：动态生成与User一致的UserTemp结构体 #

如果你确实需要一个独立的UserTemp结构体，由于Go是静态类型语言，我们可以通过反射或者代码生成来实现：

方式1：利用反射复制结构体字段与标签 #

通过反射可以动态创建一个和User结构、标签完全一致的新类型：

import "reflect"

// 更新后的User结构体
type User struct {
    ID        uint   `gorm:"primaryKey"`
    Username  string `gorm:"size:50;unique"`
    NewBio    string `gorm:"type:text"`
}

// 反射获取User的结构体类型
userType := reflect.TypeOf(User{})
var structFields []reflect.StructField

// 逐个复制User的字段（包括名称、类型、标签）
for i := 0; i < userType.NumField(); i++ {
    field := userType.Field(i)
    structFields = append(structFields, field)
}

// 动态创建UserTemp结构体类型
userTempType := reflect.StructOf(structFields)

// 创建UserTemp实例并执行迁移
userTempInstance := reflect.New(userTempType).Interface()
err := db.AutoMigrate(userTempInstance).Error
if err != nil {
    // 错误处理
}

这种方式可以动态生成结构体，但要注意反射的性能开销，以及Gorm对反射生成结构体的标签兼容性（亲测大部分场景下是没问题的）。

方式2：代码生成（更稳定可靠） #

如果你的迁移脚本是提前编写的，用代码生成工具自动生成UserTemp结构体是更稳妥的选择。比如可以用go generate：

1. 编写一个生成脚本gen_user_temp.go，读取User结构体的定义，输出一个完全一致的UserTemp结构体
2. 在你的模型文件顶部加上//go:generate go run gen_user_temp.go
3. 执行go generate就会自动生成UserTemp结构体，之后直接用db.AutoMigrate(&UserTemp{})即可

额外的零停机迁移注意事项 #

• 在从user向user_temp同步数据时，要注意迁移过程中新写入user表的数据，建议用双写或者数据库触发器的方式，确保数据不丢失
• 表重命名（步骤4、5）操作在大多数数据库中是原子性的，耗时很短，但还是要尽量在低峰期执行
• 重命名完成后，先验证服务能正常读取新的user表，确认无误后再删除user_old表

备注：内容来源于stack exchange，提问作者mrwuscience