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