GORM事务失败后不重置结构体字段，因其只保障数据库原子性，不管理内存状态；user.Name等字段保持修改值，ID仍为0，关联字段亦不回滚，需手动通过重新初始化、map备份或深拷贝恢复。
事务执行失败后，GORM 不会自动“重置”实体状态——user.Name 还是改过的值，user.ID 可能已是零值或旧值，关联字段也未必回滚。这不是 bug，而是 ORM 的合理行为：它只管数据库层面的原子性，不负责内存中结构体的“快照还原”。
为什么 GORM 不重置结构体字段？
GORM 的 Create、Save、Updates 等方法操作的是传入的结构体指针，所有字段变更都发生在内存里。事务回滚只影响数据库写入，不会反向修改 Go 对象本身。你看到的“状态混乱”，本质是业务代码把数据库状态和内存状态混为一谈了。
- 事务失败时，
db.Create(&user)若报错，user.ID通常仍是 0（MySQL 自增未生效），但user.Name已是你赋的值，不会变回去 - 若用
db.Session(&gorm.Session{FullSaveAssociations: true}).Save(&user)，失败后关联结构体（如user.Address）字段仍保留原值，但数据库里没插入成功 - 更隐蔽的是时间字段：
CreatedAt可能已被 GORM 自动设为当前时间，事务回滚后这个 struct 字段依然存在，但数据库无记录
手动重置的三种实用方式
没有银弹，选哪种取决于你控制粒度的需求：
-
最轻量：重新初始化结构体 —— 适合简单场景，比如创建失败后立刻重试
user = User{Name: "alice", Email: "a@example.com"} -
带原始数据恢复：用 map 或 json 备份 —— 适合需要保留部分中间状态的流程
orig := map[string]interface{}{"name": user.Name, "email": user.Email}，失败后user.Name = orig["name"].(string) -
强一致性要求：用指针 + 深拷贝 —— 适合含嵌套结构、切片、指针字段的复杂模型
用github.com/mohae/deepcopy或gob编码再解码，避免浅拷贝陷阱；注意time.Time和sql.NullString等类型需额外处理
别踩这些坑
很多团队在重试逻辑里栽在这几个点上：
- 在事务外修改了结构体字段，又进事务调用
Save，失败后误以为“没变”，其实字段早被污染了 - 用
Updates更新部分字段后事务失败，却直接拿原结构体继续下一次Updates，导致漏掉本该重置的字段 - 对关联切片（如
user.Orders []Order）做了append，事务失败后切片长度已变，但数据库没存任何东西——这属于典型的内存状态与 DB 状态脱节 - 依赖
db.First回查来“重置”，但在高并发下可能查到别人刚插入的数据，反而引入新问题
真正关键的不是“怎么重置”，而是明确区分“哪部分状态必须由数据库决定”“哪部分可以安全保留在内存”。事务失败后，数据库状态是确定的（空或旧值），而 Go 结构体只是个临时载体——把它当草稿纸，写完就扔，比试图擦干净再用更可靠。
