GridFS是为突破MongoDB单文档16MB限制设计的分块存储方案，适合元数据强关联、文件中等大小（2MB–100MB）、需原子性读写的场景，而非通用文件系统替代品。
GridFS 不是用来替代文件系统的，它是为了解决 MongoDB 单文档 16MB 限制而设计的分块存储方案。如果你正考虑用 GridFS 存图片、日志或小视频，先确认你是否真的需要它——多数场景下，用对象存储（如 S3）+ 数据库存路径更稳。
GridFS 什么时候该用？
适合「元数据强关联 + 文件中等大小（2MB–100MB）+ 需要原子性读写」的场景，比如用户头像（带 user_id、upload_time）、内部报表 PDF（需和订单记录事务一致）、微服务间共享的配置模板。
- 文件超过 16MB，又不想拆成多个文档手动管理 →
GridFS自动分块（默认 255KB/块） - 需要按
filename、metadata查询文件（如db.fs.files.find({ "metadata.project": "billing" })） - 要求文件读写与数据库事务语义对齐（MongoDB 4.4+ 支持在单次会话中绑定
GridFSBucket和普通写操作） - 部署环境受限（无法接入外部存储，且文件量不大、QPS 不高）
为什么不能直接存 base64 到普通字段？
Base64 编码会使体积膨胀约 33%，且把二进制塞进 BSON 字段会快速触达 16MB 上限；更重要的是，MongoDB 无法对 base64 字符串做流式读取或范围查询，每次都要全量加载解码 —— 内存压力大、延迟不可控。
-
GridFS的fs.chunks表支持按n字段顺序读块，实现真正的流式下载 - 客户端驱动（如
pymongo）提供open_download_stream()，可 pipe 到 HTTP 响应或本地文件，不占 Python 进程内存 - 如果硬存 base64，连
$regex都没法用 —— 它不是文本，是编码后的字符串
GridFS 的实际坑点有哪些？
最常被忽略的是 chunk 大小和索引缺失问题。默认 255KB 分块看似合理，但对大量小文件（如千张 100KB 图片），会产生海量 fs.chunks 文档，拖慢 find() 和复制延迟。
- 调整块大小需在 bucket 初始化时指定：
bucket = GridFSBucket(db, chunk_size_bytes=512*1024)，之后无法修改 -
fs.files和fs.chunks默认只有_id索引，查filename必须手动建：db.fs.files.createIndex({"filename": 1}) - 删除文件用
delete()而非remove()，否则只删files行，留下孤儿chunks - GridFS 不支持 TTL 索引，想自动清理过期文件得靠定时任务扫
uploadDate
真正难处理的不是怎么存，而是怎么删干净、怎么查得快、怎么和现有备份策略对齐。比如 oplog 不包含 GridFS 操作细节，跨集群同步时容易漏 chunk；再比如 mongodump 默认不导出 fs.* 集合，得显式加 --collection fs.files --collection fs.chunks。
