GridFS本身不限制单个文件大小，其设计目标就是存储大于16 MiB的文件；实际限制需在应用层通过文件大小预检、HTTP层配置（如Nginx client_max_body_size）及数据库监控等组合策略实现。
GridFS 本身不限制单个文件大小
GridFS 的设计目标就是存放大于 16 MiB 的文件，它不提供内置的“最大文件尺寸”开关。你无法通过 fs.put()、bucket.openUploadStream() 或任何 GridFS 配置项直接设置类似 maxFileSize: 100 * 1024 * 1024 这样的参数。所有驱动（Python、Node.js、Java）都默认允许上传任意大的文件——只要磁盘和内存撑得住。
必须在应用层拦截超限文件
真正能起作用的限制，只能由你自己在调用 GridFS 之前做判断。常见错误是：等 fs.put() 执行完才发现文件太大，此时数据已写入 fs.chunks，再删就多一次 I/O 开销。
- Node.js 中，在
createReadStream()前先用fs.statSync(filePath).size检查，超过阈值直接throw new Error("file too large") - Python 中，上传前读取
os.path.getsize(filepath)，别依赖gridfs.GridFS.put()的返回值来判断是否成功 - 如果走 HTTP 接口（如 FastAPI/Express），务必在
req.file或request.body解析前，通过content-length头或流式预读前几 KB 做快速拦截
注意 chunk 大小 ≠ 文件大小限制
很多人混淆 chunkSizeBytes（默认 256 KiB）和文件上限。这个参数只控制每个 fs.chunks 文档存多少字节，不影响总文件长度。改它不会让 GridFS “拒绝 200 MiB 文件”，只会改变块数量和元数据分布密度。
- 设成 1 MiB：块更少，
fs.chunks文档数减少，但单个文档变大（仍 ≤ 16 MiB） - 设成 32 KiB：块更多，元数据查询压力略升，但随机读某一段更精细
- 无论怎么调，
fs.files里length字段仍可存任意大的整数，MongoDB 不校验它是否“合理”
真正要防的是误传和资源耗尽
限制不是为了满足某种规范，而是防止用户上传 50 GiB 视频把磁盘打满，或并发上传压垮连接池。所以实际策略往往组合使用：
- Web 层：Nginx 设置
client_max_body_size 200m，先拦掉 HTTP body 超限请求 - 应用层：检查
file.size或content-length，提前return错误响应 - 数据库层：监控
fs.chunks的文档增长速率，配合 TTL 索引自动清理未完成上传（fs.files中uploadDate未更新的记录）
别指望 MongoDB 或 GridFS 自动帮你守门——那个门，得你自己焊死在应用入口。
