直接插入或更新超16MB文档会失败，这是BSON协议层硬限制；需用Object.bsonSize()精确检测单文档大小，接近16777216即临界点；GridFS不支持对fs.chunks或fs.files聚合查询，必须另建元数据集合并严格关联file_id。
直接插入或更新超16MB文档会失败，这不是配置能绕过的——Payload document size is larger than maximum of 16MB 或 BsonMaximumSizeExceededException 是 BSON 协议层的硬拦截，请求根本不会进存储引擎。
怎么快速确认是文档超限？
别猜，用 Object.bsonSize() 精确测：
db.collection.findOne({ _id: ObjectId("...") })
// 在 shell 里执行：
Object.bsonSize(doc)
输出接近 16777216 就是临界点。聚合管道中也得查中间结果大小，加 explain("executionStats") 看 executionTimeMillisEstimate 和内存峰值，超限常伴随 OOM 或 pipeline 中断。
- 日志里看到
Document too large或payload size exceeds limit，基本就是它 -
mongostat显示大量netIn骤增但写入失败，配合应用层报错可交叉验证 - 别依赖
db.collection.stats().avgObjSize—— 它只反映平均值，单个 outlier 才是真凶
GridFS 存完为啥不能直接聚合查内容？
因为 fs.chunks 和 fs.files 是系统集合，结构固定、字段不可索引、不支持聚合操作：
- 对
fs.chunks执行$match或$group直接报错：errmsg: "cannot use $group in fs.chunks" -
fs.files.filename是字符串，但默认没索引；uploadDate是ISODate，也没业务语义字段 -
fs.chunks.data是BinData类型，聚合管道里连$regex都不认
想按 deviceId 或 errorCount 过滤？必须另建元数据集合，且 file_id 字段必须严格等于 fs.files._id（ObjectId 类型），否则 $lookup 关联失败。
元数据集合该怎么设计才真正可用？
核心原则：只存摘要字段，所有查询字段显式建索引，上传时原子写入。
-
file_id必须是ObjectId，值与fs.files._id完全一致 - 别复制整个大 JSON 结构进去——只存
deviceId、timestamp、status、durationMs这类可索引字段 - 每个需用于
$match/$sort的字段都要单独建索引，例如：db.large_docs_meta.createIndex({ deviceId: 1, timestamp: -1 }) - 上传大文件时，必须用事务包裹
bucket.open_upload_stream()+ 元数据insertOne()，否则元数据缺失就查不到
示例元数据文档：
{
"_id": ObjectId("..."),
"file_id": ObjectId("..."), // ← 必须和 fs.files._id 一模一样
"deviceId": "sensor-789",
"timestamp": ISODate("2026-07-20T14:22:00Z"),
"errorCount": 3,
"size_bytes": 24567890
}
分表（子文档拆分）什么时候会更麻烦？
拆成多个子文档只在逻辑独立、查询模式固定时有效；一旦涉及跨文档统计或全局排序，问题反而更重：
- 要查“过去30天所有日志中 errorRate = errorCount / totalCount”，就得先拉出几百个子文档再客户端算——MongoDB 不支持跨文档数组统一计算
- 分页跳转到第 10001 条日志？
db.logs.find({ parentId: "user1" }).sort({ timestamp: 1 }).skip(10000)效率极低，且无法保证顺序绝对严格 - 更新一条子文档后，主文档里的
totalLogCount不会自动同步，得靠双写或变更流监听，增加复杂度
真正适合拆分的场景：评论列表、订单明细这类彼此无依赖、查询总是“先主后子”、数量可控（几百条内）的数据。
最易被忽略的一点：chunkSizeBytes 调整只对新文件生效，旧文件块大小不变；而 fs.chunks 的复合索引 { files_id: 1, n: 1 } 是读取顺序拼接的关键，删错一块整个文件就损坏——别手动碰 fs.chunks。
