MongoDB单文档BSON硬限制16MB，超限即报DocumentTooLarge错误；该限制源于BSON协议int32长度字段设计，无法通过配置绕过，须拆分集合或重构模型应对。
Document too large for BSON 错误直接中断写入
当 insertOne、updateOne 或 replaceOne 尝试写入一个序列化后超过 16MB 的文档时，MongoDB 驱动会立即报错：Document too large for BSON。这不是超时或慢查询，而是服务端在解析 BSON 前就拒绝接收——BSON 解析器根本不会尝试解包，直接返回错误。所有语言驱动（Java、Python、Node.js）行为一致，且不区分插入还是更新：哪怕只是给一个已有 15.9MB 的文档 $push 一条新评论，只要整体超限，操作立刻失败。
为什么不是“截断”或“自动分片”，而是硬限制
MongoDB 的 16MB 限制是 BSON 协议层的刚性约束，不是可调优的配置项。它源于底层二进制格式设计：BSON 文档开头 4 字节存整个文档长度，用 int32 表示，最大值就是 2³²−1 ≈ 4.3GB？不对——实际实现中，MongoDB 为安全和性能预留了缓冲与校验空间，最终将单文档上限锁定在 16MB（即 16 × 1024 × 1024 = 16777216 字节）。这个数字无法通过 setParameter 或启动参数绕过，也不是 WiredTiger 引擎的限制，而是整个通信协议栈的基石。
常见触发场景和误判点
最容易被忽略的是“隐式膨胀”：
- 你以为只存了一条日志，但应用层自动注入了完整堆栈（
stack字段含几千行文本） - 前端传来的富文本内容未清洗，嵌入了 base64 编码的图片（一张 2MB 的 PNG 直接吃掉八分之一额度）
- 使用
$addToSet累积标签，但没做去重或长度校验，某用户打上了 5000+ 个长字符串标签 - 聚合结果写回（
$out）时，中间$group聚出一个超大数组，比如按用户统计其全部操作日志并塞进logs字段
注意：GridFS 不是通用解法——它专用于文件存储（如图片、PDF），不能替代业务文档建模。把评论、日志、订单明细扔进 GridFS，会导致无法用 find 查询、无法加索引、无法参与聚合管道。
真正有效的应对方式只有三种
别试图压缩、分块或改驱动：
- 对持续增长型数据（如评论、操作日志、消息记录），必须拆成独立集合，用
article_id或user_id建索引，查时用find({ article_id: ObjectId("...") }) - 对偶发大字段（如文章正文），保留主文档精简结构（标题、摘要、作者、状态），大内容单独存
articles_content集合，靠_id关联 - 对分析类聚合结果，不要
$out到业务集合，改用临时集合 + TTL 索引自动清理，或导出到专用分析库
最危险的操作，是发现快超限时，临时启用 allowDiskUse: true 或加大 maxTimeMS——它们完全不影响 16MB 上限，只会掩盖问题，让下次崩溃更突然。
