GORM级联更新需显式配置关联标签并包裹事务，否则Save仅更新主表；必须传完整结构体指针、确保外键非零或为0（由GORM自动填充），且子结构体指针非nil，Preload与Upsert均不支持级联写入。
GORM 的级联更新默认不生效，必须显式配置关联关系 + 开启事务，否则 Save 或 Updates 只会更新主表，子表数据被忽略甚至意外清空。
gorm 中级联更新依赖两个前提条件
级联更新不是“打开开关就自动运行”的功能，它由模型定义和操作方式共同决定：
-
BelongsTo、HasOne、HasMany等关联标签必须正确声明，且外键字段名与结构体字段一致（例如UserID uint对应user_id） - 调用
Save时传入的是完整结构体指针（含关联字段），不能只传 map 或部分字段；若用Updates，它不触发级联，只会更新当前表 - 外键字段值必须非零（如
UserID: 123），否则 GORM 会认为要解除关联，把外键设为NULL或 0 - 如果子结构体用了指针类型（如
*Address），且该指针为nil，GORM 不会创建新记录，也不会报错 —— 这是常见静默失败点
事务包裹是防止数据不一致的硬性要求
即使关联定义正确，单条 Save 仍可能因网络中断、主键冲突或外键约束失败导致主表写入成功而子表失败。必须用事务兜底：
- 用
db.Transaction(func(tx *gorm.DB) error { ... })包裹整个操作，内部所有tx.Create/tx.Save共享同一连接和事务上下文 - 不要在事务内混用
db和tx，比如tx.Save(&u)后又用db.Create(&a)，后者会脱离事务 - 事务中避免调用未受控的第三方函数（如 HTTP 请求、文件写入），它们无法回滚，破坏原子性
- 注意
Preload不影响写操作，它只用于查询；级联写必须靠Save或Create配合结构体嵌套
实际写法：嵌套结构体 + 事务 + 显式赋值
以下是最小可验证模式，适用于用户带地址的一对一场景：
type User struct {
gorm.Model
Name string
Email string
Address Address `gorm:"foreignKey:UserID"`
}
type Address struct {
gorm.Model
UserID uint
City string
Zip string
}
// 正确做法：构造完整结构体，确保 UserID 被赋值，用事务包裹
err := db.Transaction(func(tx *gorm.DB) error {
u := User{
Name: "Alice",
Email: "a@example.com",
Address: Address{
UserID: 0, // 注意：这里会被 Save 自动填充为 u.ID，前提是 u.ID 尚未设置
City: "Beijing",
Zip: "100000",
},
}
if err := tx.Save(&u).Error; err != nil {
return err
}
return nil
})
关键点：Address.UserID 设为 0 是安全的 —— GORM 在 Save(&u) 时会先插入 User，拿到自增 ID 后再填入 Address.UserID 并插入子表。但如果 User.ID 已手动指定（比如 UUID），就必须同步设好 Address.UserID，否则外键为空。
容易踩的坑：预加载不等于级联保存，Upsert 不支持嵌套
很多人误以为 Preload("Address") 能让后续 Save 自动处理地址，其实它只影响查询结果；同理，FirstOrCreate 或 Clauses(clause.OnConflict{...}).Create 均不递归处理关联结构体：
-
db.Preload("Address").First(&u, 1)→ 正确加载用户+地址，但db.Save(&u)仍只更新用户表 -
db.Clauses(clause.OnConflict{DoNothing: true}).Create(&u)→ 即使u.Address非空，地址也不会被插入或更新 - 若需 Upsert 关联数据，必须拆成两步：
tx.FirstOrCreate(&u, ...)→ 拿到u.ID→ 手动构造并tx.Save(&u.Address)
级联更新真正落地的难点不在语法，而在结构体生命周期管理：你得清楚每个字段何时被赋值、是否允许为零、外键如何对齐 —— 这些细节一旦错位，数据就 silently 失去关联。
