beego orm 的 update 方法不支持原生批量更新，仅作用于单个模型实例；批量更新应使用 querytable().filter().update() 方式，或事务循环 update，手动 sql 需防注入。
Beego ORM 的 Update 方法不支持原生批量更新
Beego 自带的 ORM（beeorm）底层基于 database/sql，其 Update 方法默认只作用于单个模型实例。直接对切片调用 Update 会报错或静默失败——比如传入 []*User，它只会尝试更新第一个元素，其余被忽略。
常见错误现象：no rows affected、返回值为 0、部分数据未更新但无报错。
- 必须先调用
o.Read()或o.LoadRelated()确保主键字段已加载（否则Update无法定位行） -
Update依赖结构体的pktag（如`orm:"pk;auto"`），缺失或错配会导致更新失败 - 若用
o.QueryTable("user").Filter("id__in", ids).Update(conds)，这是可行的替代路径，但注意：它绕过模型验证和钩子（PreUpdate不触发）
用 QueryTable().Update() 实现安全的批量条件更新
这是 Beego ORM 中最常用、也最可控的批量更新方式，适用于“按条件统一修改多个记录”的场景（例如：将一批订单状态设为已发货）。
它本质是生成一条 SQL UPDATE ... WHERE 语句，性能好、原子性强，且不依赖模型实例状态。
- 语法：
o.QueryTable(&User{}).Filter("id__in", []int{1,2,3}).Update(orm.Params{"status": 2}) -
Filter支持多种操作符：id__gt、name__contains、created__gte，但注意__in的值必须是切片，不能是数组 - 更新字段名必须是数据库列名（非结构体字段名），除非你显式设置了
columntag；例如orm:"column(user_name)"对应的更新 key 应为"user_name" - 不支持跨表 JOIN 更新；如需关联更新，得拆成两步：先查 ID，再用 ID 批量更新
手动拼接 SQL 批量更新（需要绕过 ORM 安全限制）
当业务要求「每条记录更新不同字段值」（例如：不同用户设置不同积分），QueryTable().Update() 就不够用了，此时必须手写 SQL 或使用事务+循环。
Beego 提供了 o.Raw() 接口，可执行原生语句，但要注意 SQL 注入风险和类型转换问题。
- 推荐方式：用
o.Begin()+ 循环o.Update()+o.Commit()，适合数据量小（PreUpdate 钩子的场景 - 大数据量时，用
o.Raw("UPDATE user SET score = CASE id WHEN ? THEN ? WHEN ? THEN ? END WHERE id IN (?,?)", ...).Exec()，但 Beego 不内置CASE WHEN参数展开，需手动拼接参数切片 - 避免直接字符串格式化拼 SQL：
"UPDATE user SET score=" + strconv.Itoa(score)—— 这是典型注入漏洞点
更新后如何获取影响行数与错误处理
Beego ORM 的 Update 和 Raw().Exec() 都返回 sql.Result，可通过 RowsAffected() 判断是否真的更新了数据，而不是仅靠 error 为空就认为成功。
-
num, err := o.QueryTable(&User{}).Filter("status", 0).Update(orm.Params{"status": 1})；若err == nil && num == 0，说明没有匹配记录，不是 bug 是预期行为 - 事务中某次
Update失败，必须显式调用o.Rollback()，否则后续Commit()仍可能成功（取决于驱动实现） - MySQL 中遇到
ErrLockWaitTimeout或context.DeadlineExceeded，说明并发更新冲突，需重试逻辑，Beego 不自动重试
真正容易被忽略的是：批量更新时的事务隔离级别和锁范围。比如 WHERE id IN (1,2,3,4,5) 在 RR 级别下可能锁住整个索引区间，而不只是这 5 行——这在高并发写场景下会成为瓶颈。
