批量更新必须用updates而非update；updates支持map或struct并需显式where条件，字段名为数据库列名，零值被忽略，updatedat标签无效，pg子查询需避坑，建议100–500行/批并手动事务。
批量更新必须用 Updates，不是 Update
用 Update 做批量意图操作，基本等于埋雷。它只接受单条记录（依赖主键），若传入空模型或没主键的结构体，GORM 会报 missing WHERE clause 或静默失败——尤其在 MySQL 中容易误以为成功，实则一行都没改。
Updates 才是批量更新的正解，它支持 map[string]interface{} 或 struct，并配合 Where 精确控制作用范围。关键点：
- 必须显式写
Where条件，不加就全表更新，且无确认机制 - 字段名是数据库列名（如
"updated_at"），不是 struct 字段名（如"UpdatedAt"） - 传 struct 时零值（
0、""、nil）会被忽略；要确保更新，必须用 map 显式列出所有目标字段 -
UpdatedAt标签在Updates中不生效，时间字段需手动赋值，例如"updated_at": time.Now()
PostgreSQL 下 WHERE 含子查询会报 invalid reference to FROM-clause entry
这是 PG 特有的 SQL 生成限制：GORM 在 Where 里用了子查询（比如 Where("id IN (SELECT id FROM ...)") ），再接 Updates，生成的嵌套语句会违反 PG 的别名可见性规则。MySQL 和 SQLite 通常不报，但 PG 会直接拒掉。
稳妥解法只有两个：
- 先查 ID 列表：
var ids []uint; db.Model(&User{}).Where(...).Pluck("id", &ids)，再Where("id IN ?", ids).Updates(...) - 绕过 ORM，用
db.Exec("UPDATE ... WHERE id IN (?)", ids)拼原生 SQL（注意参数绑定安全，勿字符串拼接）
升级到 GORM v2.2.5+ 可缓解部分简单子查询场景，但复杂逻辑仍建议放弃 ORM 层抽象。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
一次更新多少行才算“安全”
没有全局最优值，但 100–500 行/批是多数数据库的甜点区间：
- 太小（如 10 行）：网络往返和事务开销摊不薄，性能提升有限
- 太大（如 10 万行）：MySQL 可能触发
max_allowed_packet截断，PG 容易锁表超时，内存占用陡增 - 建议按实际单行数据大小估算：假设平均 2KB/行，500 行 ≈ 1MB，远低于默认 4MB 上限
- 务必手动包事务：
tx := db.Begin(); tx.Where(...).Updates(...); tx.Commit()，否则某批失败时前面批次已提交，数据不一致
想自动更新时间戳？别指望钩子
BeforeUpdate 或 UpdatedAt 标签在 Updates 批量操作中完全不触发——GORM 的钩子只对单条 Save、Create、Update 生效。
所以如果你依赖 updated_at 字段做业务判断（比如幂等校验、同步位点），漏写这行就会出问题：
db.Where("status = ?", "pending").Updates(map[string]interface{}{
"status": "processing",
"updated_at": time.Now(), // 必须显式写
})
更隐蔽的坑是字段映射：如果数据库列叫 last_modified，但你在 map 里写了 "UpdatedAt"，那这个字段根本不会被更新，也不会报错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
