发布于2026-07-17 阅读(0)
扫一扫,手机访问
在平时的开发中,InsertOne、UpdateOne、Find、DeleteOne 这四个方法几乎覆盖了 MongoDB 的日常操作,但很多人直接套用示例代码时,往往会遇到空引用异常或无效操作异常——根本原因不是语法错误,而是驱动版本升级后,BsonDocument 的构造逻辑和异步支持方式发生了变化。

InsertOneAsync 而不是 Insert,否则会阻塞线程旧版驱动(比如 1.x 时代)允许同步插入:collection.Insert(doc);但 2.10+ 版本已经彻底移除了这个方法,只保留异步入口。如果强行用同步包装(比如 .Result),在 ASP.NET Core 中极易引发死锁。
await collection.InsertOneAsync(doc),且所在方法需标记 async Taskdoc 可以是 BsonDocument,也可以是强类型实体(如 new User { Name = "Alice" }),驱动会自动完成序列化_id,别再手动 new ObjectId() 了:用 result.InsertedId 拿返回值即可Find 查询时过滤器写法不匹配,查不到数据却无报错Find 方法接受 FilterDefinition,不是随便传个 BsonDocument 就行。常见错误是把 JSON 字符串或裸 BsonDocument 直接塞进去,结果过滤器被忽略,返回全量数据(或者空结果)。
collection.Find(Builders.Filter.Eq(u => u.Status, "active")) & 连接:Builders.Filter.Eq(...). & Builders.Filter.Gt(...) BsonDocument,必须转成 FilterDefinition:collection.Find(new BsonDocument("status", "active")) 是错的;应写 collection.Find(FilterDefinition.Parse("{status: 'active'}")) DeleteOne 和 DeleteMany 的返回值容易被忽略删除操作不抛异常,绝不等于成功删除了文档。驱动返回 DeleteResult,其中 DeletedCount 才是真实删除数量——常见陷阱是只检查是否抛异常,却没验证 result.DeletedCount > 0。
ObjectId 类型,不是字符串:new ObjectId(id);否则过滤器匹配失败,DeletedCount 恒为 0DeleteMany:没有事务回滚,删错无法撤回;生产环境建议先 CountDocuments 预估数量$set 不是默认行为UpdateOne 默认是“替换整个文档”,不是“局部更新”。如果传一个不带 _id 的实体进去,原 _id 会被丢弃,MongoDB 自动生成新 _id,旧文档其实还在。
Builders.Update.Set(u => u.Name, "Bob") Builders.Update.Set(...).Set(...).Set(...) Unset:Builders.Update.Unset(u => u.A vatarUrl) Eq(u => u.Id, id)),可能误改全表真正难的不是写对某一行代码,而是每个操作背后隐含的语义约束:插入是否要校验唯一索引、查询是否用了未建索引的字段、更新是否触发了 TTL 或变更流——这些不会在编译时报错,但上线后立刻暴露。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8