根本不是GridFS本身的问题，而是上传链路中某处将整个文件加载进内存导致OOM或超时；必须使用流式读取、禁用同步解析、预校验文件大小、设置合理超时、避免IFormFile隐式加载，并按顺序清理中断残留数据。
根本不是 GridFS 本身的问题，而是上传链路中某处把整个文件加载进了内存，V8 堆或 JVM 堆直接撑爆，还没写进 MongoDB 就已经 OOM 或超时中断。
Node.js 里 fs.readFileSync 或 Buffer.from 是最常见死因
前端传来的文件，如果后端用 fs.readFileSync 读取本地路径，或用 FileReader.readAsArrayBuffer() + Buffer.from(arrayBuffer) 构造 Buffer，整个文件就已驻留内存。GridFS 的 uploadStream 还没开始写，进程就挂了。
- 必须改用
fs.createReadStream(path, { highWaterMark: 64 * 1024 })，绕过任何同步读取 - Express 用户务必禁用
bodyParser（尤其multipart），它默认缓存整个请求体 - Multer 场景下，直接用
req.file.stream（它是 Readable 流），别取req.file.buffer
Java 里 ByteArrayInputStream 或 available() 判断也会触发 OOM
把大文件先读成 byte[] 再塞进 ByteArrayInputStream，等同于全量加载；而调用 inputStream.available() 后再分配数组，该方法在多数网络流中返回 0，导致后续 read() 阻塞或分配错误大小。
- 直接传
FileInputStream给uploadFromStream()，它天然支持流式分块 - 上传前用
file.length()做预校验，超限直接拒绝，别让数据进管道 -
SocketTimeoutSettings.builder().readTimeout(300, TimeUnit.SECONDS)必须设，Driver 默认 60 秒太短
ASP.NET Core 中 IFormFile 绑定是隐性陷阱
IFormFile 会强制把整个文件加载进内存，哪怕你只读 FileName 或 ContentType。一旦超过默认 64MB 限制，直接抛 InvalidDataException 或 Request body too large。
- 必须在
ConfigureServices中设DisableMultipartBuffering = true - 禁用所有
Request.Form.Files、ReadFormAsync()等触发模型绑定的操作 - 直接用
Request.Body管道到bucket.OpenUploadStreamAsync()，靠CopyToAsync()流式传输
超时失败后残留的脏数据比失败本身更危险
openUploadStream() 一调用，fs.files 文档就立即插入；而 fs.chunks 是异步分批写入。中断后你大概率得到一个 length: 0 或 uploadDate: null 的元数据文档，外加一堆孤立 chunks —— 它们不会自动清理，也不会被同名覆盖。
- 上传前生成唯一
uploadId（如 UUID）并写入metadata.uploadId，清理时可精准定位 - 清理必须严格按顺序：先删
fs.chunks，再删fs.files，反序会留永久孤儿块 - 服务端
operationTimeout要用db.adminCommand({ setParameter: 1, operationTimeout: 300000 })动态调，客户端socketTimeout无效
真正卡住人的从来不是“怎么传”，而是“谁在偷偷把文件全读进内存”和“断了之后怎么收场”。这两个点漏掉任何一个，上传大文件就是定时炸弹。
