GORM不支持SQL JOIN多表UPDATE，因其绕过模型校验、钩子和事务管理，且MySQL/PostgreSQL语法限制；正确做法是用事务包裹多个单表操作，并注意顺序、锁、字段映射与钩子触发。
为什么GORM的多表联合更新不能靠SQL JOIN写一条语句
因为GORM本身不支持跨表UPDATE语法，db.Exec("UPDATE a JOIN b ON a.id = b.a_id SET a.status = ?, b.updated_at = ?")这种写法不是GORM能力范围，而是直连驱动的原始SQL操作——它绕过了GORM的模型校验、钩子、软删除等机制，也失去了事务自动管理能力。更关键的是，MySQL对多表UPDATE的语法支持有限（比如不支持子查询中引用被更新的表），PostgreSQL则根本**不支持**多表UPDATE。所以“联合更新”在GORM语境下，实际是指“多个单表操作在同一个事务中协调执行”。
必须用事务包裹所有单表更新操作
多表更新天然面临部分成功、部分失败的风险。GORM不会自动帮你兜底，db.Create()或db.Updates()各自独立提交，不加事务就等于裸奔。
- 显式调用
tx := db.Begin()开启事务，别依赖中间件或全局配置 - 每个更新操作后必须检查
tx.Error，一旦出错立即tx.Rollback() - 所有操作成功后再调用
tx.Commit()，不要把Commit()写在defer里——它无法捕获中间错误 - 如果涉及主从库或分库，事务只在当前
*gorm.DB实例内生效，跨库更新需另做补偿逻辑
更新顺序和外键约束容易引发死锁或违反完整性
比如订单表orders依赖用户表users，先更新users再更新orders可能触发外键检查失败；反过来又可能因行锁顺序不一致导致死锁。这不是Go的问题，是数据库MVCC和锁机制决定的。
- 按外键依赖方向执行：先更新被引用表（如
users），再更新引用表（如orders） - 所有UPDATE都带上
WHERE id = ?精确条件，避免全表扫描锁升级 - 批量更新时用
IN而非循环单条，减少网络往返和锁持有时间 - 若更新字段含
DeletedAt（软删除），记得用Unscoped()，否则Where("id = ?").Updates()查不到已软删记录
前端传来的局部更新字段怎么安全合并进数据库
前端只传{"status": "shipped"}，但GORM的Save()会把结构体零值（如UpdatedAt: time.Time{}）写进数据库，覆盖原有时间戳。直接Updates(map[string]interface{})又没法触发BeforeUpdate钩子。
- 用
Model(&obj).Select("status").Updates(updates)限定只更新指定字段，避开零值污染 - 若需运行钩子（如自动更新
UpdatedAt），改用Model(&obj).Omit("CreatedAt").Updates(updates)，保留时间字段由GORM自动处理 - 对关联表（如订单明细
order_items），先Unscoped().Where("order_id = ?", orderID).Delete(&OrderItem{})清空，再遍历新数组Create()——避免手动比对增删改的复杂度 - 所有
updatesmap的key必须是数据库列名（如"status"），不是Go字段名（如"Status"），否则GORM找不到对应字段
