GridFS 无法限制单文件大小，因它只是协议且无内置拦截机制，MongoDB 的 maxSize 等参数仅影响分块不阻止上传，BSON 16MB 限制已被绕过，故需应用层在上传前校验长度并返回 413 错误。
GridFS 本身不限制单个文件大小，但应用层必须拦截超限上传——否则可能因内存爆满、网络中断或服务假死导致失败，且错误反馈模糊。
为什么不能依赖 GridFS 或 MongoDB 配置来限制单文件尺寸
GridFS 是协议，不是服务；fs.chunks 和 fs.files 集合没有内置的 per-file size 拦截机制。MongoDB 的 maxSize 参数（如在 openUploadStream 中）仅影响 chunk 分配行为，不阻止上传。BSON 16MB 限制只作用于普通文档，而 GridFS 已绕过它，所以你不会看到 Document too large 错误，而是遇到更难排查的问题：
- Python 进程 OOM（尤其用
f.read()加载整个大文件时） - HTTP 请求超时（Nginx 默认 60s，上传 2GB 文件大概率触发）
-
put()卡住无响应，日志里只有BrokenPipeError或空异常
在 Python 应用中做上传前长度校验的实操要点
别等 fs.put() 开始才检查——要在读取流之前就拿到文件总长。常见误区是以为 request.files['file'].stream 一定支持 seek(0, 2) 获取长度，其实多数 Web 框架（如 Flask 的 FileStorage）返回的是不可回溯的流。
- Flask 场景：用
request.files['file'].filename+request.headers.get('Content-Length')做初步判断（注意：该 header 可被伪造，仅作快速过滤） - 更可靠方式：先
read(1)再seek(0)，确认是否支持随机访问；不支持则改用临时文件或分块预读统计 - 硬性上限建议设为 2GB（
2 * 1024**3），避开 32 位整数溢出和某些驱动的内部限制 - 校验失败时，直接返回
413 Payload Too Large，别进 GridFS 流程
PyMongo 的 put() 调用中哪些参数会影响实际上传体积控制
put() 自身不校验大小，但几个参数间接决定你能否安全完成上传：
-
chunk_size_bytes：默认 255KB，调大（如设为1024*1024）可减少fs.chunks文档数量，但不改变总容量——只是分块策略 -
metadata字典里可存{'original_size': os.stat(f.name).st_size}，方便后续审计，但不参与校验逻辑 - 传入的文件对象必须保持打开状态直到
put()返回；若提前close()，会抛ValueError: I/O operation on closed file - 避免传字符串或 bytes —— 这会让 PyMongo 尝试一次性加载全部内容到内存，直接触发 OOM
容易被忽略的边界情况和并发风险
单文件尺寸限制看似简单，但和用户配额、代理层、客户端行为交织后容易失效：
- 前端用
fetch上传时，若未设body为FormData，而是拼 JSON，可能触发中间件（如 Express 的body-parser）对 payload 的默认限制（常为 100KB） - Nginx 的
client_max_body_size必须 ≥ 你的应用层上限，否则请求根本到不了 Python - 多个上传请求并发抵达时，如果只靠
Content-Length初筛 +put()后写 metadata，仍可能因时间差导致瞬时超限（比如两个 1.2GB 文件同时通过初筛） - 真正可靠的方案是：初筛 → 临时落盘（或内存 buffer）→ 校验确切字节数 → 成功后再进
fs.put()；虽然多一步 IO，但杜绝了所有“以为限制了其实没拦住”的情况
最易漏掉的一点：校验逻辑必须覆盖所有上传入口，包括管理后台的直接 API、第三方回调、CLI 工具脚本——只要路径通向 fs.put()，就必须有同一套尺寸检查。
