不能直接对 fs.chunks 求和，因为其 data 字段受压缩、padding 和 BSON 开销影响，真实文件大小应取 fs.files 的 length 字段；需 $match 过滤 length > 0 且无软删除标记，再 $group 求和。
为什么不能直接对 fs.chunks 求和
GridFS 将文件拆成 fs.chunks（数据块）和 fs.files（元信息）两个集合。每个 fs.chunks 文档的 data 字段是二进制，但实际存储大小受压缩、padding 和 BSON 开销影响，Object.bsonSize() 也不适用于聚合管道。真正可靠的文件大小来自 fs.files 的 length 字段——它代表原始文件字节数，是 GridFS 规范定义的权威值。
用 $group 对 fs.files 的 length 求和最稳妥
直接在 fs.files 集合上聚合，避免跨集合 join 或误算 chunk 数量。注意：必须确保只统计“已完整写入”的文件，即排除 uploadDate 为空或 length 为 0 的脏数据。
- 基础求和语句：
db.fs.files.aggregate([ { $match: { length: { $gt: 0 } } }, { $group: { _id: null, totalBytes: { $sum: "$length" } } } ]) - 如需按文件类型分组统计：
db.fs.files.aggregate([ { $match: { length: { $gt: 0 }, "metadata.contentType": { $exists: true } } }, { $group: { _id: "$metadata.contentType", count: { $sum: 1 }, totalBytes: { $sum: "$length" } } } ]) - 加
$project转换字节数为 MB（保留两位小数）：{ $project: { _id: 0, totalMB: { $round: [{ $divide: ["$totalBytes", 1024 * 1024] }, 2] } } }
过滤条件写错会导致结果虚高或漏计
常见错误包括：$match 放在 $group 后、用 fs.chunks 的 files_id 去关联但没去重、忽略已删除文件（GridFS 不物理删除，只靠应用层标记）。真实场景中建议：
- 若业务有软删除字段（如
deletedAt），必须显式排除：{ deletedAt: { $exists: false } } - 避免用
$lookup关联fs.chunks计数——chunk 数量 ≠ 文件数，且性能差 - 时间范围查询优先用
uploadDate（ISODate 类型），别用字符串匹配 - 大集合上执行前先
db.fs.files.createIndex({ uploadDate: 1 })加速
聚合结果超 16MB 时会报 errmsg: "aggregation result exceeds maximum document size"
这是 MongoDB 的单文档限制。即使总和只是一个数字，$group 输出仍是一个文档。如果 totalBytes 是一个极大整数（比如几百 TB），BSON 编码后可能突破 16MB —— 实际极少发生，但一旦触发，唯一解法是改用 MapReduce 或客户端分片累加。不过更常见的原因是误把整个 fs.files 文档投影进了结果，忘了加 $project 只留必要字段。
真正容易被忽略的是：不同驱动对大整数的处理差异。Node.js 的 mongodb 驱动返回的是 Long 对象，Python 的 pymongo 默认转成 int，但超过 2^53 会丢失精度。需要显式调用 .toString() 或使用 Int64 类型处理超大值。
