mgo是Go语言中经典的MongoDB驱动程序，虽然官方已经转向更现代的mongo-go-driver，但大量遗留项目仍在使用mgo。对于插入操作，开发者往往只关注错误是否为nil，却忽略了错误可能被延迟、部分写入失败或返回值未被充分利用。本文以Collection.Insert和InsertMany为核心，系统性地讲解如何验证插入结果并妥善处理各类错误。
mgo插入操作的基本流程与返回值
使用mgo向MongoDB插入文档的典型步骤包括：建立会话、选择数据库和集合、构造文档、调用插入方法。以单条插入为例，Collection.Insert方法接收一个interface{}类型的文档指针，执行后返回error。如果error为nil，通常可以认为插入成功，但实际情况可能更复杂。例如，在写入确认（write concern）未设置为w:1时，数据可能已进入服务器内存但尚未持久化到磁盘；在网络抖动时，客户端可能收到超时错误，但服务器端已经成功写入。因此，仅仅判断error == nil不足以证明数据已安全落盘。
mgo提供了更丰富的返回信息。Insert方法不返回插入ID，因为MongoDB的_id字段通常由客户端在插入前生成，或者允许服务端生成但需要额外查询。如果需要在插入后获取服务端生成的_id，可以使用Upsert或者Insert后执行查询。较新版本的mgo（如gopkg.in/mgo.v2）中Collection.Insert依然只有error返回，但Collection.Upsert返回(info *ChangeInfo, err error)，其中ChangeInfo包含Updated、Removed、UpsertedId等字段。对于直接需要插入ID的场景，建议在文档中预先设置_id，例如使用bson.NewObjectId()生成，这样插入后可以直接从文档结构体或map中读取。
批量插入Collection.Insert可以接收切片参数，一次插入多个文档。但需要注意的是，mgo的批量插入底层会拆分为多个单条插入，如果其中某一条失败，之前的插入可能已经成功，后续插入被中止，最终返回的错误可能只代表最后失败的那个文档。因此，批量插入的结果验证需要谨慎处理，建议结合错误信息和后续查询来判断实际成功写入的数量。
package main
import (
"fmt"
"log"
"gopkg.in/mgo.v2"
"gopkg.in/mgo.v2/bson"
)
func main() {
session, err := mgo.Dial("127.0.0.1:27017")
if err != nil {
log.Fatal(err)
}
defer session.Close()
c := session.DB("testdb").C("users")
// 单个文档插入
doc := bson.M{"name": "Alice", "age": 30}
err = c.Insert(doc)
if err != nil {
log.Printf("插入失败: %v", err)
} else {
fmt.Println("单条插入成功")
}
// 批量插入
docs := []interface{}{
bson.M{"name": "Bob", "age": 25},
bson.M{"name": "Charlie", "age": 35},
}
err = c.Insert(docs...)
if err != nil {
log.Printf("批量插入部分失败: %v", err)
}
}
验证插入结果的有效手段
要可靠地验证mgo插入操作是否成功，应当从多个维度进行确认。最直接的方式是检查error返回值，但需要理解错误产生的时机。mgo的写入操作默认使用w:1的写入关心级别，即确认写入已应用到主节点内存。如果希望确保数据已写入大多数节点或持久化，可以通过session.SetSafe设置更严格的写入关心，例如&mgo.Safe{W: 2, J: true}表示等待写入两个节点并写入日志。设置后，Insert返回的错误才更能反映持久化结果。
第二种验证手段是利用插入后文档中的_id字段。如果客户端在插入前显式设置了_id，插入成功后该值不会改变，可以直接读取；如果服务器生成_id，则可以通过Collection.Upsert的返回信息获取。例如：
newId := bson.NewObjectId()
doc := bson.M{"_id": newId, "name": "Dave"}
err = c.Insert(doc)
if err == nil {
fmt.Printf("插入成功，ID: %v\n", newId.Hex())
}
第三种验证方式是在插入后执行一次读取查询。使用c.FindId(id).One(&result)确认文档存在，可以完全排除写入未生效的情况，但会增加一次网络往返，适用于对数据一致性要求极高的场景。同时，批量插入后可以通过c.Count()粗略判断写入数量是否达预期，但需注意并发写入可能干扰计数。
还有一种实用的做法是开启mgo的调试日志，观察底层驱动的命令执行情况。通过mgo.SetDebug(true)可以打印发送到MongoDB的实际指令，帮助定位是客户端序列化问题还是服务器端拒绝写入。
常见错误类型与针对性处理
mgo插入操作可能返回多种错误，开发者需要根据错误类型采取不同策略。首先是连接类错误，例如no reachable servers，表示所有服务器不可达。这通常发生在网络故障或MongoDB服务未启动时。对于这类错误，应当立即中止操作并记录严重日志，同时可以结合重试机制进行有限次尝试，但要注意重试可能造成重复插入，因此需要保证插入文档具有幂等性或唯一索引。
第二类是重复键错误（错误码11000），当插入的文档包含已存在的唯一索引字段时触发。mgo返回的错误信息中通常包含E11000 duplicate key error字样。处理方式可以是忽略该错误（如果业务允许重复），或者更新已有文档。一个常见的做法是捕获错误并使用Collection.Upsert或Collection.Update替换为更新操作。示例：
err = c.Insert(doc)
if mgo.IsDup(err) {
// 处理重复键：改为更新
_, err = c.UpsertId(doc["_id"], bson.M{"$set": bson.M{"name": "Alice", "age": 31}})
if err != nil {
log.Printf("更新失败: %v", err)
}
} else if err != nil {
log.Printf("插入错误: %v", err)
}
第三类是写入超时错误，通常由于网络延迟或服务器负载过高导致。mgo的默认socket超时为10秒，可以通过session.SetSocketTimeout调整。对于超时错误，需要特别小心，因为客户端无法确定服务器是否已经执行了写入。此时不建议盲目重试，应当先查询目标文档是否已存在，再决定是插入还是更新。使用Upsert代替Insert可以在超时后安全重试，因为Upsert是幂等的。
健壮性实践建议
为了构建可靠的插入操作，建议在项目中封装一层数据访问函数，统一处理错误和验证逻辑。例如，定义一个InsertWithRetry函数，传入文档和重试次数，内部通过查询判断是否已写入来决定是否重试。同时，对于批量插入，尽量使用Insert的切片形式而非循环单条调用，因为mgo内部对批量插入有优化，能减少网络往返。
设置合理的写入关心级别至关重要。如果业务对数据丢失零容忍，应使用Safe{W: "majority", J: true}，但会牺牲写入性能。对于日志、临时数据等场景，可以使用Safe{W: 0}获取更高吞吐量，但必须接受可能丢失数据的风险。写入关心应当与业务需求匹配，并在文档中明确说明。
最后，不要忽略mgo会话的复制和连接池管理。通过session.Copy()为每个goroutine创建独立会话，使用完毕后调用Close()，可以避免连接泄漏导致插入失败。插入操作的错误处理应当与日志系统结合，记录足够的上下文信息（如集合名、文档摘要、耗时），便于事后排查。