本文介绍如何利用 mgo 的 Query.Apply 方法，通过单次 findAndModify 操作完成文档更新与最新状态获取，避免先 Update 再 Find 的两次往返开销，提升性能与数据一致性。
本文介绍如何利用 mgo 的 `query.apply` 方法，通过单次 `findandmodify` 操作完成文档更新与最新状态获取，避免先 `update` 再 `find` 的两次往返开销，提升性能与数据一致性。
在使用 MongoDB 驱动 mgo（v2）进行数据操作时，一个常见但低效的模式是：先调用 Update 或 Upsert 修改部分字段，再立即执行 FindId 或 Find 查询以获取更新后的完整文档。这种“更新 + 查询”两步法不仅增加网络往返延迟，还可能在并发场景下引入竞态风险——例如其他写操作在两次请求之间修改了同一文档，导致客户端拿到的并非真实最新状态。
幸运的是，mgo 提供了更优雅、原子性的解决方案：Query.Apply 方法。它底层封装了 MongoDB 原生的 findAndModify 命令，支持在一次请求中完成匹配、更新（或删除/替换）、并可选地返回修改前或修改后的完整文档。
核心用法：mgo.Change 与 Apply
关键在于构造一个 mgo.Change 结构体，明确指定更新操作及返回策略：
- Update: 使用标准 BSON 更新操作符（如 $set, $inc, $push 等）描述变更；
- ReturnNew: 设为 true 以返回更新后的文档（默认为 false，返回更新前）；
- 其他可选字段：Remove（删除匹配文档）、Upsert（不存在时插入）、Sort（多匹配时指定优先级）等。
以下是一个典型示例，假设有一个用户集合，需对指定 _id 的用户增加积分，并立即获取其完整信息（含未被更新的其他字段如 name、email、createdAt 等）：
type User struct {
ID bson.ObjectId `bson:"_id"`
Name string `bson:"name"`
Email string `bson:"email"`
Points int `bson:"points"`
CreatedAt time.Time `bson:"createdAt"`
}
// 初始化查询与变更
query := col.FindId(id)
change := mgo.Change{
Update: bson.M{"$inc": bson.M{"points": 10}},
ReturnNew: true,
}
var updatedUser User
info, err := query.Apply(change, &updatedUser)
if err != nil {
log.Fatal("Apply failed:", err)
}
// 此时 updatedUser 已包含所有字段（含 points 更新后值）
fmt.Printf("Updated user: %+v\n", updatedUser)
✅ 优势总结：
- 原子性保障：整个 find-modify-return 过程由 MongoDB 服务端串行执行，无中间状态暴露；
- 单次 RTT：仅一次网络请求，显著降低延迟与服务器负载；
- 完整性保留：无论更新操作只涉及少数字段，返回的 updatedUser 始终是数据库中该文档的完整快照。
注意事项与最佳实践
- Apply 不适用于批量操作：它仅作用于至多一个匹配文档（findAndModify 本身限制），若需批量更新并返回，请改用 Bulk 操作 + 后续 Find，或考虑 MongoDB 5.0+ 的 updateMany + pipeline 聚合更新（需结合应用层处理）。
- 错误处理需谨慎：当 query 未匹配到任何文档且未设置 Upsert: true 时，Apply 将返回 mgo.ErrNotFound；若设置 Upsert: true 则会插入新文档并返回（此时 info.Updated 为 0，info.Removed 为 0，info.UpsertedId 为新 _id）。
- 结构体标签必须准确：确保 Go 结构体字段的 bson tag 与数据库字段名严格一致，否则反序列化将丢失数据。
- 避免在高并发下依赖 ReturnNew 的“即时性”做业务决策：虽然操作原子，但若业务逻辑需强一致性读（如金融扣款），建议配合 readConcern: "majority"（需 MongoDB 3.2+ 及副本集配置）进一步保障。
通过合理使用 Query.Apply，你不仅能精简代码逻辑，更能构建出更健壮、高效的数据访问层——让一次请求，真正完成一次完整的“读-改-回”闭环。
