GridFS适用于文件超过16 MiB或需随机读取片段（如视频流、PDF预览）的场景，核心解决BSON单文档限制及range查询需求，而非单纯按文件类型选择；它不支持事务，且小文件会加剧写放大与索引压力。
GridFS 不是“适合存什么类型”，而是“适合存什么规模 + 什么访问模式”的文件。
它真正解决的不是文件后缀问题，而是 BSON 单文档 16 MiB 限制带来的硬瓶颈。只要文件超过这个大小，或者你有特定访问需求，GridFS 才值得考虑。
文件大于 16 MiB 时必须用 GridFS
这是最明确的触发条件：mongod 拒绝插入超过 16 MiB 的 BinData 字段。常见场景包括：
- 视频文件（如 MP4、MKV）——动辄几百 MB 到数 GB
- 高清医疗影像（DICOM、NIfTI）——单张可达 50–200 MiB
- 工程 CAD 模型（STEP、IGES）或 GIS 地图瓦片包（MBTiles）——常超 100 MiB
- 数据库导出备份（
.dump或.bson）——生产环境全量 dump 很容易 >16 MiB
文件虽小但需随机读取某一段时也适用
比如音频/视频流式播放、PDF 文档预览页加载、日志文件按时间范围检索——这些操作不依赖完整加载，而 GridFS 支持 range 查询（通过 skip 和 limit 控制 chunk 范围）。直接存 BinData 就得把整个文件拉进内存再切片，代价高。
-
openDownloadStream()可传{ start: 1024, end: 2048 }精确读取字节区间 - 底层靠
fs.chunks中的n字段排序和data字段拼接，驱动自动处理 - 注意：
start/end是文件内偏移，不是 chunk 编号
别误以为 “所有大文件都该放 GridFS”
它不解决性能瓶颈，反而引入额外开销：
- 每个文件至少生成 2 条文档（
fs.files+ 至少 1 条fs.chunks），写放大明显 - 默认 chunk 大小 255 KiB，小文件（如 20 MiB PDF）会被切成 ~80 个文档，索引压力上升
-
GridFS不支持多文档事务，上传中途失败会导致元数据与部分 chunks 残留（需手动清理） - 如果只是静态资源（如用户头像），且文件系统 + CDN 可控，
GridFS反而增加运维复杂度
GridFS 的价值不在“存得多”，而在“查得细”和“扩得稳”**。如果你的业务需要按时间戳筛选 10TB 日志里的某 1MB 片段，或让全球副本集自动同步最新版设计稿，那它才发挥出不可替代的作用。单纯为了“把大文件塞进 MongoDB”而用，大概率会踩坑。 
