GORM结构体tag不控制事务逻辑，仅影响字段映射与读写权限；事务仅包裹SQL执行，字段是否参与更新取决于传入值及tag中的
结构体 tag 本身不控制事务中的字段变更——事务是操作层面的控制，而 tag 只影响字段映射、约束和读写行为。真正决定“哪些字段参与写入/更新”的，是 gorm tag 中的 和 <code>-> 权限控制符，不是事务开关。
为什么 gorm:"column:xxx" 或 gorm:"primaryKey" 不影响事务逻辑
GORM 的事务（如 db.Transaction() 或 db.Session(&gorm.Session{NewDB: true})）只包裹 SQL 执行过程，不干预字段是否被生成到 INSERT/UPDATE 语句里。字段是否出现在 UPDATE 语句中，取决于：
- 你传给
Save()/Updates()/UpdateColumns()的值 - 结构体字段的 tag 是否禁用了写入（
）或仅限创建（<code>） - 字段是否为零值且未显式指定（受
AllowGlobalUpdate和零值处理策略影响）
和 <code> 在事务内怎么起作用
这两个 tag 控制字段在不同操作类型中是否被写入数据库，哪怕你在事务里调用 Create() 或 Save()，它们仍生效：
gorm:"：仅在 <code>Create()时写入，Save()或Updates()不会包含该字段gorm:"：仅在 <code>Save()/Updates()时写入，Create()忽略gorm:"：任何写操作都不写入（但查询仍可读，除非同时加 <code>->:false）
示例：
type User struct {
ID uint `gorm:"primaryKey"`
Name string `gorm:"<-:create"` // 创建时写，更新时不写
Email string `gorm:"<-:update"` // 更新时写，创建时不写
Password string `gorm:"-"` // 完全忽略（不读不写）
}
在事务中执行：
err := db.Transaction(func(tx *gorm.DB) error {
u := User{Name: "alice", Email: "a@example.com"}
if err := tx.Create(&u).Error; err != nil {
return err
}
// 此时 u.Name 已入库，u.Email 被跳过（<-:create 生效）
u.Email = "new@example.com"
if err := tx.Save(&u).Error; err != nil {
return err
}
// 此时 u.Email 被更新，u.Name 不变（<-:update 生效）
return nil
})
事务中字段变更被意外跳过的常见原因
不是事务配置问题，而是 tag 或调用方式导致字段没进 SQL：
- 写了
gorm:"column:user_name"却漏了column:前缀（比如误写成gorm:"user_name"），字段名映射失败，GORM 用默认蛇形名，若数据库列不存在则静默忽略或报错 - 用
Updates(map[string]interface{})传 map，但字段 tag 里有—— 这个限制对 map 无效，<code>Updates()会照常写入，容易造成预期外覆盖 - 结构体字段是零值（如
int是 0、string是 ""），又没加gorm:"default:..."或gorm:"null"，GORM 默认跳过零值字段写入（除非用UpdateColumns()强制） - 嵌套结构体或匿名字段没加 tag，GORM 按默认规则映射，但表里没有对应列，SQL 执行时报错，事务回滚
最易被忽略的一点：tag 的权限控制（/<code>->）在事务内完全照常工作，但它只作用于 GORM 自动生成的语句；如果你手写 Exec("UPDATE ...")，这些 tag 就彻底失效了。
