gridfs不支持聚合查询，须另建元数据集合存储可索引业务字段，并与fs.files._id严格关联；fs.chunks和fs.files结构固定、不可直接聚合或按内容查询。
GridFS 本身不支持聚合查询，必须配合元数据集合
直接用 GridFSBucket 存完大 JSON 后，别指望在 fs.chunks 或 fs.files 上跑 $match、$sort 或 $lookup —— 这两个集合结构固定，字段不可索引（如 fs.files.filename 是字符串，但没建索引；fs.chunks.data 是二进制，根本不能查内容）。所有“按业务字段筛选大文件”的需求，都得靠额外建一个元数据集合来承载可查询字段。
常见错误现象：
- 在
fs.files上加{ filename: 1 }索引后仍无法按时间范围排序 —— 因为uploadDate是 ISODate，但默认没索引，且不包含业务语义字段（如deviceId、status） - 试图对
fs.chunks做聚合，结果报错errmsg: "cannot use $group in fs.chunks"—— 这是设计限制，不是权限或语法问题
正确做法是：上传时同步写一条元数据文档，其中 file_id 字段存 uploadStream.id（ObjectId 类型），其他字段全按业务需要设计：
-
file_id必须与fs.files._id严格一致，否则$lookup关联失败 - 所有需用于查询/排序的字段（如
timestamp、status、deviceId）都要显式存入元数据集合，并单独建索引 - 避免把原始 JSON 的完整结构复制进元数据集合 —— 只存摘要字段（如
errorCount、durationMs），否则又回到超限老路
分表（拆文档）不是万能解，要警惕关联查询开销
当大文档本质是“逻辑一体、物理可分”的数据（比如用户十年日志、传感器每秒采样点），拆成多个子文档确实可行，但必须明确代价：
- 单次业务查询可能变成 1 次主文档 + N 次子文档查询，应用层需自己合并 —— MongoDB 不支持跨文档数组展开后统一排序
- 如果子文档间有强顺序依赖（如日志按毫秒时间戳严格递增），靠
parentId关联后，db.logs.find({ parentId: "user1" }).sort({ timestamp: 1 })能工作，但分页会变复杂（无法用$skip/$limit直接取第 10001 条） - 更新某条子文档时，无法原子性地同时更新主文档的统计字段（如
totalLogCount），需应用层双写或触发器（4.2+ 支持变更流监听，但增加运维负担）
适用场景有限：
- 子文档彼此独立（如评论列表），无跨文档计算需求
- 查询模式固定为“先查主文档，再按 ID 批量拉子文档”，且子文档数量可控（
- 你愿意为节省存储成本，接受应用层多一次 round-trip
外部对象存储 + MongoDB 元数据是最轻量的方案
如果大文件只是“存住、能取、偶尔查属性”，不涉及 MongoDB 内部聚合或事务，直接扔 S3/OSS/MinIO 更干净。MongoDB 只存这三条信息：
-
url：带签名或权限控制的直链（如s3://my-bucket/reports/abc123.json?X-Amz-Signature=...） -
metadata：BSON 对象，存contentType、sizeBytes、checksum等校验字段 -
refId：业务主键（如reportId），用于和其它集合$lookup
优势明显：
- 完全规避 16MB 限制，连 GridFS 的 chunk 分片逻辑都不用管
- 对象存储天然支持断点续传、多线程下载、CDN 加速
- 备份恢复解耦：MongoDB 备份元数据，对象存储走自己的生命周期策略
坑点在于权限收敛 —— 如果 url 是临时签名链接，过期后前端直接 403；若用长期公开链接，又存在泄露风险。建议元数据里存原始 key（如 reports/abc123.json），由后端网关统一鉴权并代理转发。
别忽略 $bsonSize 和监控预警
等报出 Document exceeds 16MB 错误才处理，已经晚了。生产环境必须前置检测：
- 用聚合管道实时扫描大文档：
db.collection.aggregate([ { $project: { size: { $bsonSize: "$$ROOT" } } }, { $sort: { size: -1 } }, { $limit: 5 } ]) - 在应用写入前做体积预估：Node.js 驱动可用
new BSON.Document(doc).toBuffer().length，Java 驱动用document.toBsonDocument().getByteSize() - 设置告警阈值别卡死 16MB —— 建议 12MB 就触发企业微信/钉钉告警，留出缓冲空间（比如新增一个字段就超限）
最容易被忽略的是：分片集群中，某个 chunk 里恰好聚集了多个接近 16MB 的文档，导致迁移时失败。这时光看单文档大小不够，还得结合 sh.status() 观察 chunk 分布和大小分布。
