无主键表在gorm事务中批量更新危险，因gorm依赖主键判断insert/update，否则易全表插入或误更新；应改用db.exec配明确where条件，并验证rowsaffected。
事务中对无主键表执行批量更新为什么危险
无主键表在 GORM 里无法被 Save 或 Update 正确识别为“已有记录”，因为 GORM 默认依赖主键判断是 INSERT 还是 UPDATE。一旦你把一个没有主键的结构体传给 db.Transaction 内的 Save 或 Updates，它大概率会全部走 INSERT，或者因 WHERE 条件缺失而误更新全表——尤其当事务里混用 Model(&s).Where(...) 时，GORM 可能忽略 Where 而仍按全字段更新逻辑走。
正确做法：用原生 SQL + Exec 替代 ORM 更新
对无主键表，别强行套 ORM 的更新语义。直接用 db.Exec 发送带明确 WHERE 条件的 UPDATE 语句，由你自己控制影响范围和原子性：
- WHERE 条件必须覆盖足够多的列（比如组合唯一索引字段），避免意外全表更新
- UPDATE 语句里显式列出要改的字段，不依赖结构体零值判断
- 把
db.Exec放在事务内，确保失败可回滚
示例：
err := db.Transaction(func(tx *gorm.DB) error {
result := tx.Exec("UPDATE logs SET status = ? WHERE service = ? AND created_at > ?", "processed", "api", time.Now().Add(-24*time.Hour))
if result.Error != nil {
return result.Error
}
if result.RowsAffected == 0 {
return errors.New("no rows matched for update")
}
return nil
})
如果非要用结构体映射，必须手动构造 WHERE 和 SET
你可以用 db.Table("logs").Where(...).Updates(...)，但要注意：
-
Where必须显式传入完整过滤条件，不能依赖结构体字段自动推导 -
Updates接收map[string]interface{}或 struct，但 struct 中未设置的字段不会进 SET，这点比Save安全 - 仍然要检查
RowsAffected，防止 WHERE 匹配不到行却静默成功
错误示范：tx.Model(&Log{}).Where("service = ?", "api").Updates(Log{Status: "done"}) —— 这里 Log{} 是空结构体，Model 不带主键，GORM 可能忽略 Where 直接发全表 UPDATE。
安全写法：tx.Table("logs").Where("service = ? AND date >= ?", "api", "2026-10-18").Updates(map[string]interface{}{"status": "done"})
容易被忽略的点：日志与影响行数验证
无主键表的批量更新操作，没有主键就失去天然的“单行唯一性”校验。线上出问题往往不是语法错，而是 WHERE 条件写宽了，或时间范围算错了。所以：
- 事务里每次
Exec或Updates后，必须检查RowsAffected是否符合预期（比如预估更新 1000 行，结果是 10000，立刻 abort） - 开启 GORM 的
SlowThreshold日志，让这类批量语句自动打 Warn，方便事后审计 - 避免在事务中嵌套多次无主键表更新 —— 每次都得重验 WHERE，逻辑易失控
