gridfs是mongodb内置的文件分块存储规范，将大文件切分为默认256kb的chunk存入fs.chunks集合，元数据存入fs.files集合；它不是对象存储，不支持cdn、生命周期、细粒度权限等企业级能力。
GridFS 不是对象存储，它只是 MongoDB 内置的一套文件分块规范；而阿里云 OSS、AWS S3 这类才是真正的对象存储服务——两者根本不在同一抽象层级上。
GridFS 是什么，不是什么
GridFS 是 MongoDB 驱动层实现的一组约定：把大文件切块存进 fs.chunks，元数据写进 fs.files，所有逻辑都在客户端驱动里完成。它不提供 HTTP 接口、不支持 CDN、没有跨域配置、不能设生命周期规则，也不做权限分级（比如只读/私有/签名 URL）。它甚至不处理并发覆盖时的 chunk 清理——open_upload_stream() 忘记调用 .end()，就留脏数据在磁盘上。
常见误解是把它当成“MongoDB 版 OSS”，但其实它连基本的对象存储语义都没覆盖。
OSS 类服务的核心能力 GridFS 全都不具备
你如果需要以下任意一项，GridFS 就不是选项：
- 通过 HTTPS 直链访问图片或视频（OSS 提供域名 + 签名 URL；GridFS 必须走应用层代理）
- 自动绑定 CDN 并刷新缓存（OSS 控制台点几下；GridFS 得自己写回源逻辑）
- 设置文件 90 天后自动转低频、180 天后删除（OSS 生命周期策略；GridFS 没这概念）
- 按 bucket 级别配 RAM 子账号权限（OSS 支持精细到 prefix 的读写控制；GridFS 权限只能落到整个 MongoDB 数据库）
- 防误删（OSS 有版本控制 + 跨区域复制；GridFS 删除就是物理删，没回收站）
什么时候真该选 GridFS？
只有两个硬条件同时满足时才值得考虑：
- 你的业务文档和文件必须强绑定，比如每份
contracts文档都对应一个 PDF，且经常要db.contracts.aggregate([{$lookup: {...}}])一起查 - 你已经重度依赖 MongoDB 复制集/分片架构，并明确拒绝再运维一个独立存储系统（哪怕只是加一台 OSS SDK）
注意：事务不是理由——GridFS 本身不支持多文档事务，fs.files 和 fs.chunks 的写入不是原子的；所谓“事务联动”其实是应用层自己兜底做的两阶段提交。
小文件场景下 GridFS 成本高得反直觉
存一个 1KB 的日志文件，GridFS 实际落盘 4.2–8.3KB：
-
fs.files元数据文档固定占 220–280 字节（含_id、filename、uploadDate） -
fs.chunks即使只塞 1KB 数据，WiredTiger 最小分配单元 + BSON 封装也让单 chunk 占 4–8KB - 索引开销更吓人：
fs.files.filename索引对每个文件名都建项；百亿文件下这个索引轻松超 100GB
而同样存 1KB，OSS 是纯对象存储，无元数据膨胀、无索引、无 chunk 拼接延迟——上传即完成，URL 即可用。
真正容易被忽略的不是“能不能用”，而是“用着用着磁盘悄悄涨、查询越来越慢、运维同学半夜被 fs.chunks 索引暴涨告警叫醒”——这些细节比选型本身更早暴露问题。
