Go语言MongoDB如何增删改查_Go语言MongoDB CRUD教程【基础】

先说几个核心判断：MongoDB 从 5.0 版本开始，旧的 mgo 驱动基本就断了生路，现在还在用它连新版本，八成是连接失败。官方驱动虽然功能完整，但坑也不少——最典型的，就是所有操作都得传 context，不传的话，轻则超时失控，重则整个 goroutine 直接挂死。

所以，动手之前，先把下面这三件事刻在脑子里。

别用 mgo，现在连不上 MongoDB ≥ 5.0；所有操作必须传 context，否则可能卡死或超时失控。

连接前必须做三件事：URI 编码、client.Ping、带 timeout 的 mongo.Connect

想象一下这个场景：密码里带着 @ 或 / 这样的特殊字符，你直接往 URI 里一丢，mongo.Connect 一声不吭地失败，日志里只抛一句“invalid URI”，连哪儿出的错都不说。这不是 bug，是你忘了做 URL 编码。

正确的做法是：密码 pa@ss/word 得写成 pa%40ss%2Fword。编码后的 URI 长这样：mongodb://user:pa%40ss%2Fword@host:27017。

还有更隐蔽的坑：mongo.Connect 返回的 client 并不等于连接已经通了。它只是发起了一个请求，真正的 TCP 握手和认证，得靠 client.Ping(ctx, nil) 来验证。没调 Ping 就直接查数据，遇到 TLS 认证失败或权限不足，错误会被吞成 context deadline exceeded，你八成会跑去调超时时间，结果完全跑偏。

再说 context。别图省事直接传 context.Background() 或 context.TODO()，必须用 context.WithTimeout 包一层。否则 DNS 解析卡住、网络抖动，整个 goroutine 就真挂死了。代码写法应该是这样的：

ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
mongo.Connect(ctx, opts)

InsertOne 后怎么拿到新文档的 _id？别指望回去读原始 struct

Go 结构体字段首字母小写，即便你加了 bson:"_id" tag，InsertOne 也不会把 _id 写进去。MongoDB 会自己生成一个，但你完全拿不到。这是新手最容易踩的坑。

正确姿势是：结构体字段名必须首字母大写，比如 ID string bson:"_id,omitempty"。插入之后，唯一能拿到的 ID 来自 InsertOneResult.InsertedID，类型是 interface{}，实际通常是 primitive.ObjectID，需要断言转换：

res, _ := collection.InsertOne(ctx, doc)
id := res.InsertedID.(primitive.ObjectID)

千万别去读插入前的 doc.ID，值一定是空字符串或零值——因为 BSON 序列化时直接跳过了未导出的字段。

UpdateOne 不报错 ≠ 更新成功：检查 MatchedCount 和过滤器写法

这是另一个大坑。UpdateOne 找不到匹配文档时不会 panic，返回的 MatchedCount 是 0。很多新手以为“更新成功”只是没改到数据，其实是过滤器写错了。

过滤器得用 bson.M 或 bson.D，别用 map[string]interface{}。如果涉及嵌套字段，比如 profile.email，路径里的点号一个都不能少——写 "profileemail" 就是匹配失败。

查 _id 时必须转类型：传字符串会匹配不上，因为 BSON 类型不匹配。正确写法是 bson.M{"_id": primitive.ObjectIDHex("64a1b2c3d4e5f67890123456")}。

更新完成后，一定要加这么一句：

if result.MatchedCount == 0 {
    log.Printf("no doc matched filter: %+v", filter)
}

字段名拼错、大小写不一致、嵌套路径漏点号，这些低级错误都会导致 MatchedCount == 0，而你不加检查根本发现不了。

Find 后不 cursor.Close 会泄漏 goroutine 和内存

collection.Find 返回的 *mongo.Cursor 是有状态资源，底层拿着网络连接和缓冲区。不显式 cursor.Close(ctx)，哪怕函数已经 return 了，goroutine 也会卡在等待下一批数据，最终拖垮连接池。

正确的模式是：Find 之后立刻写 defer cursor.Close(ctx)。

解码时也有讲究：cursor.Decode 必须传指针，否则解码会失败但不报错，结果 slice 里全是零值。解码单条的写法：

var doc MyStruct
if err := cursor.Decode(&doc); err != nil { ... }

循环解码时，每次必须新建变量或重置指针，复用同一个变量地址会导致后续 decode 覆盖前值。

最后提醒一个最容易被忽略的细节：所有操作都依赖 context 的生命周期。如果你在一个 HTTP handler 里传进来的 ctx 被 cancel 了，正在跑的 Find 或 UpdateOne 会立刻中断——这不是 bug，是设计。但如果你没处理好 error 分支，结果就是“请求没响应也不报错”。这才是最头疼的。