第2章 文档模型与CRUD：写错数据的两种方式
第 2 章 · 文档模型与 CRUD：写错数据的两种方式
章节摘要：本章讲 BSON 数据类型与增删改查。对应两起事故：把金额存成 double 导致对账差一分钱、一条 deleteMany 条件写漏导致整集合被清空。读完本章，你能按类型正确建模字段，并安全地执行 CRUD。
学习目标
- 能说出 BSON 与 JSON 的差异及常用扩展类型；
- 能解释 ObjectId 的构成与"为何近似递增"；
- 能用 insertOne/find/updateOne/deleteOne 完成日常读写；
- 能识别会导致事故的写法（double 存钱、无条件删除、replace 语义误用）。
核心概念速览
金句：MongoDB 里没有"建表"这一步，但类型的代价一步都不会少——JSON 没有的坑，BSON 全都有配套版本。
子章节导航
- 2.1 BSON 数据类型：对账差一分钱的事故，讲 double 与 Decimal128、日期与 ObjectId。这一节的复盘认真拆了定位过程——如何用 $type 聚合把"看不见的类型错误"变成可统计的分布，以及存量数据如何安全迁移。附带 int/long/double 的选择依据和跨语言映射的坑。
- 2.2 CRUD 操作：误删集合的事故，讲四类操作的安全写法与更新操作符。除了"先 count 再删"的纪律，还覆盖 bulkWrite 的有序无序差异、深分页的键集翻页写法、findOneAndUpdate 的原子组合——这些是日常代码评审里最常打回来的几类写法。
子章节之间的逻辑关系
先懂类型再动手写：2.1 决定"数据长什么样"，2.2 决定"怎么安全地读写它"。两起事故其实互为镜像——一个是写入时类型随手定了、日后对不上账；一个是删除时条件随手丢了、当下就清了库。前者慢性，后者急性，但共同根源都是"MongoDB 不替你把关字段名和类型"。
类型正确(2.1) ──► 操作安全(2.2) │ │ 金额用 decimal 删除先 count 再删
如果只能从本章带走一句话：字段名拼错和类型选错都不会报错，它们只会在几周后以业务故障的形态回来找你。写前的三分钟校对，是对付这两类沉默错误唯一的廉价手段。
本章知识点核对清单
离开本章前逐条自查：能否说出金额字段为什么必须用 Decimal128 而不是 double，并解释二进制浮点在 0.1 上的表示误差；能否默写 $type 聚合统计字段类型分布的语句；能否解释 ObjectId 四段构成与近似递增的原因；能否写出防超卖的单文档条件更新；能否说出 deleteMany 前的两步保命动作；能否区分 replaceOne 与 updateOne 的语义差异并说出各自误用的后果；能否把一个深分页接口改写成键集翻页。答不上的条目，回对应小节的事故复盘里再走一遍。
再给代码评审一份三行照妖镜：凡是金额或费率字段，查类型是否 Decimal128；凡是 deleteMany 或 updateMany，查是否先 count 并限定集合与条件；凡是分页用 skip 的，查数据量增长后是否会退化为全表扫描。三行检查覆盖了本章两起事故的全部形态，评审时对号入座即可。
类型问题的时间差
类型事故最阴险之处在于时间差：写入那一刻一切正常，报表和对账几周后才暴露，定位窗口被拉得很长。缩短窗口的办法是在写入侧加校验（第 5 章的 jsonSchema）并在日报里盯类型分布的异常漂移。
前置知识与后续延伸
前置：第 1 章装好的实例。延伸：CRUD 只是读写原语，查询性能依赖第 3 章的索引，复杂分析依赖第 4 章的聚合。