Buffalo框架不支持ActiveRecord式批量更新语法，必须通过pop.Raw()手写SQL或Query().Update()实现；禁用循环Save()，须显式事务、参数化查询及主键WHERE条件保障一致性与安全。
buffalo 框架本身不提供类似 ActiveRecord 的 update_all 或 upsert_all 语法，批量更新必须绕过默认的单行 Save() 流程，直接走 SQL 层或 pop 的底层能力。硬套 models.Update() 或循环 Save() 会触发 N+1 查询、事务膨胀、锁竞争，生产环境基本不可用。
用 pop.Connection.Raw() 手写 UPDATE 语句
这是最可控、性能最高、也最贴近企业级需求的方式。Buffalo 默认使用的 pop ORM 支持原生 SQL 执行，且能复用连接池和事务上下文。
- 必须显式开启事务：否则多条 UPDATE 可能部分成功，破坏数据一致性
- WHERE 条件务必带主键或唯一索引字段，避免误更新整表（尤其线上环境）
- 参数需用
?占位符，由Raw().Exec()自动转义，禁止字符串拼接 - 注意 PostgreSQL 与 MySQL 的语法差异：PostgreSQL 要用
UPDATE ... FROM (VALUES ...)实现批量 upsert，MySQL 可用INSERT ... ON DUPLICATE KEY UPDATE
示例（MySQL 场景，更新用户状态）：
tx, _ := models.DB.Transaction()
defer tx.Close()
sql := `UPDATE users SET status = ?, updated_at = ? WHERE id IN (?)`
_, err := tx.Raw(sql, "active", time.Now(), []int{101, 102, 103}).Exec()
if err != nil {
tx.Rollback()
return err
}
return tx.Commit()
用 pop.Query().Where().Update() 避免手写 SQL
当批量条件简单（如统一修改某字段值 + 固定 WHERE）时，pop 提供了轻量封装，比 Raw 更安全，但灵活性受限。
- 只支持单字段赋值，无法实现“status = CASE WHEN id=1 THEN 'a' ELSE 'b' END”这类逻辑
- WHERE 必须是等值判断或范围（
IN,BETWEEN），不支持子查询或 JOIN 条件 - 返回影响行数，可用于校验是否更新了预期数量的记录
- 自动使用当前连接（含事务上下文），无需手动管理
tx
示例（更新所有未确认邮箱的用户为待审核状态）：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
q := models.DB.Where("email_confirmed = ?", false)
rows, err := q.Update("status", "pending")
if err != nil {
return err
}
if rows == 0 {
// 注意：这里不是错误，但业务上可能需要告警
}
别在 action 里循环调用 Save() 做“伪批量”
这是新手最常踩的坑——把一个切片遍历后对每个模型实例调 Save()，表面看是“批量”，实则每轮都发一次 SQL、占一次连接、启一次事务（除非外层已开事务）。
- 100 条记录 = 100 次 round-trip，延迟爆炸，数据库连接池极易打满
- 哪怕加了
tx.Save(&u)，也仍是 100 次独立 UPDATE，没解决本质问题 - 如果某条失败，前面成功的无法自动回滚（除非你手动捕获并 rollback）
- Buffalo 的
c.Param()/c.Request().Body解析逻辑不针对批量结构优化，容易出错
真正要批量，就别碰 model.Save()；真要逐条处理，就承认它是“串行操作”，别包装成“批量接口”误导调用方。
前端传参结构与后端绑定取舍
批量更新接口的请求体设计，直接影响后端解析复杂度和安全性。
- 推荐用数组传 ID + 单独字段传更新值：
{"ids": [1,2,3], "status": "archived"}—— 后端校验ids长度（防 DOS）、查库确认存在、再执行统一 UPDATE - 避免接收完整对象数组：
[{"id":1,"status":"a"},{"id":2,"status":"b"}]—— 解析成本高，且难以原子性保证全部成功或全部失败 - 若必须按 ID 分别设不同值，应走 Upsert 场景，改用
INSERT ... ON CONFLICT DO UPDATE（PostgreSQL）或REPLACE INTO（MySQL），而非 UPDATE - 所有 ID 必须经
strconv.Atoi或uuid.Parse校验，禁止直接透传进 SQL
真正难的不是写 UPDATE，而是确定哪批数据该被更新、谁有权限更新、更新前后要不要发事件、失败时怎么通知上游——这些逻辑不会因为用了 pop 就自动消失。
