MongoDB 的单文档大小上限为 16MB，这对于绝大多数 JSON 数据来说绰绰有余，但当你需要存储高清图片、视频文件、压缩包或者备份文件时，这个限制立刻变得棘手。直接把文件编码成 Base64 塞进一个文档，不仅会受到大小限制，还会让查询和索引效率急剧下降。MongoDB 官方给出的解决方案就是 GridFS——一个基于文档模型的大文件存储规范。
GridFS 并没有引入额外的存储引擎，而是利用两个标准的集合（fs.files 和 fs.chunks）将文件拆分成若干小块（chunk）进行管理。这种设计既保持了 MongoDB 的水平扩展能力，又使得文件元数据和内容本身都能被索引和查询，非常适合那些需要频繁访问文件属性、却不想引入单独文件服务器的小型到中型文件存储系统。
GridFS 的底层存储模型
GridFS 的核心思想是分块。当一个文件被写入时，GridFS 会将其分割成默认 255KB 的 chunk（可通过 chunkSizeBytes 参数调整），每个 chunk 作为独立的文档存入 fs.chunks 集合。同时，在 fs.files 集合中插入一条文档，记录文件的元数据，例如文件名、上传时间、MD5 校验值、chunk 的大小和数量等。
fs.files 集合的文档结构大致如下：
{
"_id": ObjectId("..."),
"length": 104857600,
"chunkSize": 261120,
"uploadDate": ISODate("2025-01-01T00:00:00Z"),
"filename": "video.mp4",
"metadata": {
"author": "admin",
"type": "video/mp4"
}
}
而 fs.chunks 集合则存储实际的数据块：
{
"_id": ObjectId("..."),
"files_id": ObjectId("..."), // 关联 fs.files 的 _id
"n": 0, // 块序号，从0开始
"data": BinData(0, "...") // 二进制数据
}
这种设计的一大好处是，files_id 和 n 组成的复合索引保证了顺序读取的高效性。当你需要读取文件时，GridFS 会根据 fs.files 中的 chunkSize 和 length 计算出需要的块数量，然后按 files_id 和 n 的顺序依次从 fs.chunks 中取出数据流，在应用层重新组装成完整的文件。因为每个 chunk 都是独立的文档，所以流式处理变得十分自然——你可以在获得第一个块的同时就开始将数据推送给客户端，而不必等待整个文件加载完毕。
值得一提的是，GridFS 并不是一个独立的组件，而是一种约定。只要按照上述结构读写，任何支持 MongoDB 的语言都可以实现 GridFS，而官方提供的驱动程序已经内置了相应的 API，极大地降低了使用门槛。
在 Node.js 中使用 GridFS 存储和检索文件
这里以 Node.js 为例，使用官方 MongoDB 驱动中的 GridFSBucket 来演示文件的上传、下载和删除操作。首先确保已安装 mongodb 包，并连接到 MongoDB 实例。
上传文件的函数可以这样实现，利用可读流将文件直接写入 GridFS：
const { MongoClient, GridFSBucket } = require('mongodb');
const fs = require('fs');
async function uploadFile(client, filePath, filename) {
const db = client.db('mydb');
const bucket = new GridFSBucket(db, { bucketName: 'videos' });
const uploadStream = bucket.openUploadStream(filename, {
metadata: { uploadedBy: 'system' },
chunkSizeBytes: 1024 * 512 // 512KB
});
const readStream = fs.createReadStream(filePath);
readStream.pipe(uploadStream)
.on('error', (err) => console.error('Upload error:', err))
.on('finish', () => console.log(`File ${filename} uploaded. File ID: ${uploadStream.id}`));
}
这里通过 openUploadStream 创建写入流，将本地文件流管道连接，所有分块和元数据插入操作都在后台自动完成。你可以通过 chunkSizeBytes 调整块大小，较大的块能减少文档数量，但会增加单次读取的缓冲开销；较小的块则有利于随机读取和细粒度的并发，但会生成更多文档。通常默认的 255KB 是一个平衡的选择，但像视频这类顺序访问的大文件，可以考虑 512KB 甚至 1MB 的块大小以提高吞吐量。
下载文件同样使用流式接口，避免将整个文件加载到内存：
async function downloadFile(client, fileId, destPath) {
const db = client.db('mydb');
const bucket = new GridFSBucket(db, { bucketName: 'videos' });
const downloadStream = bucket.openDownloadStream(fileId);
const writeStream = fs.createWriteStream(destPath);
downloadStream.pipe(writeStream)
.on('error', (err) => console.error('Download error:', err))
.on('finish', () => console.log(`File downloaded to ${destPath}`));
}
如果想按文件名下载，可以使用 openDownloadStreamByName，但注意如果存在同名文件，它只会返回最新的一个，通常建议使用唯一 ID 进行下载以保证精确性。删除操作则更为直接，通过 delete 方法传入文件 ID，GridFS 会自动清理所有的 chunks 和 fs.files 文档。
对于大文件并发上传或下载的场景，官方驱动内置了连接池和流控机制，不必担心一次性打开过多流导致资源耗尽。但务必注意错误处理，例如网络中断时管道可能提前关闭，需要监听 error 事件并记录未完成的块，以便通过应用程序重试或补偿逻辑保证数据完整性。
GridFS 的适用边界与替代方案
GridFS 并非银弹。它的最大优势是让你在同一个 MongoDB 集群内同时管理结构化数据和非结构化文件，省去了单独部署文件服务器或对象存储的维护成本。对于文件大小在几十 MB 到几 GB 之间的图片、音视频素材、报表文件，GridFS 提供的原子更新、按条件查询和简单的权限控制都非常顺手。尤其是当你需要频繁根据文件元数据（如标签、上传者、分类）进行筛选，又要直接返回文件内容时，GridFS 让数据库和应用之间的交互变得异常简洁。
然而，它的缺点也很明显。首先，所有文件内容都以 BSON 二进制形式存放在文档中，这会显著增加 MongoDB 的存储开销。BSON 编码会使实际存储空间比原始文件大 10%~20%，对于海量小文件或超大规模部署，成本会快速增长。其次，GridFS 的读写性能受限于 MongoDB 的磁盘 IO 和复制延迟，当文件量达到 TB 级别时，备份、恢复和复制都可能成为瓶颈。此外，虽然 chunk 文档可以跨分片分散，但同一文件的 chunks 通常会聚集在同一个分片上，无法像对象存储那样实现极致的水平扩展。
因此在选型时，需要明确你的主要诉求。如果系统已经重度依赖 MongoDB，且文件存储只是辅助功能，文件总量在几百 GB 以内，GridFS 可以帮你快速落地，避免引入额外的技术栈。一旦文件数量激增，或者需要全球 CDN 分发、版本管理、生命周期策略等高级特性，就应该转向专门的对象存储服务（如 Amazon S3、MinIO）。多语言和混合架构中，常见的折中方案是“元数据存 MongoDB，文件本身存对象存储”，通过文件的 URL 或 Key 关联两者的关系。这样做既保留了 MongoDB 强大的查询能力，又享受了对象存储的海量容量和低成本。
此外，如果你的文件普遍小于 16MB，不妨考虑直接使用 BinData 类型将整个文件嵌入文档。这种做法避免了分块管理的复杂度，并且在网络传输中可以一次获取完整文件，适合头像、缩略图这类小资源。但必须谨慎控制单文档的大小，避免影响复制集的 oplog 和整体响应时间。
最后，生产环境中使用 GridFS 时，应该监控 fs.chunks 的数量和平均大小，定期清理孤立文档（例如上传中断留下的 chunk），并合理规划索引。默认情况下 fs.chunks 已对 {files_id: 1, n: 1} 建了唯一索引，但你还可以根据文件元数据在 fs.files 上创建额外索引来加速查询。只要量力而行，GridFS 就能在关系型文件管理和对象存储之间扮演一块结实的跳板。