GridFS本质是为突破MongoDB单文档16MB限制而设计的分块存储机制，非安全方案；它通过fs.files和fs.chunks两个集合将大文件切分为默认255KB的数据块存储，绕过BSON协议限制，但不提供加密、权限控制或事务一致性保障。
GridFS 本质是分块存储，不是“更安全”的替代方案
GridFS 不提供加密、权限控制或防篡改等传统意义上的“安全”能力。它解决的核心问题是：单个 BSON 文档不能超过 16MB。当你试图用 BinData 直接存一个 50MB 的视频或 ZIP 包到某个字段里，MongoDB 会直接拒绝插入，并抛出错误：Document too large for BSON encoding。这不是安全性问题，而是协议硬限制——BSON 规范本身就不允许单文档超 16MB。
为什么不能只靠 base64 + 字符串字段绕过 16MB 限制
有人尝试先把文件转成 base64 字符串再存进 String 类型字段，这依然会失败，原因有二：
- base64 编码会使原始二进制体积膨胀约 33%，原本 12MB 的文件变成约 16MB 字符串，已逼近上限；稍大一点就必然超限
- MongoDB 对字符串字段长度没有单独放宽，它仍受整个文档 16MB 总限制约束，且索引、嵌套开销会让可用空间更少
GridFS 如何实际工作：两个集合 + 自动分片
GridFS 是客户端驱动的约定，底层使用两个标准集合：
-
fs.files：存元数据（filename、uploadDate、length、chunkSize等），每条记录对应一个文件 -
fs.chunks：存真实数据块，默认每块255KB（可配置chunkSizeBytes），每个块是独立文档，远低于 16MB 上限
例如上传一个 100MB 文件，GridFS 客户端会自动切成约 400 个 fs.chunks 文档，每个都合法；读取时按 files._id 查所有关联 chunks 并拼回。这个过程对应用透明，但必须用官方驱动的 GridFSBucket（如 Node.js 的 mongodb.GridFSBucket）或 mongofiles 工具，不能手写 insertOne 模拟。
容易被忽略的代价和陷阱
GridFS 不是银弹。它带来新问题：
- 原子性仅限单个 chunk，整个文件不支持事务（即使在 4.0+ 的多文档事务中，
fs.files和fs.chunks也不能跨集合原子写入） - 无法对文件内容做查询（比如“找出所有包含某段二进制签名的 PDF”），
fs.chunks.data是BinData，不能建有效索引 - 删除文件需两步操作（删
fs.files记录 + 清理对应fs.chunks），若只删一半会残留垃圾块 - 默认 chunk 大小影响性能：太小 → chunk 数量爆炸、查询放大；太大 → 内存压力高、小文件浪费空间
真正需要“安全”的场景（如敏感文件加密、访问审计），得在 GridFS 之上叠加应用层处理，而不是依赖它本身。
