GridFS上传失败时uploadFromStream可能假成功：返回ObjectId但仅写入部分chunk，因默认不校验完整性且TCP异常未被捕获；需await fileStream.finished()、监听error、上传后校验chunk数量。
GridFS 上传失败时 uploadFromStream 不抛错但写入不全？
这是弱网下最典型的假成功现象：Node.js 驱动的 uploadFromStream 在网络中断或超时后可能返回一个看似有效的 ObjectId，但实际只写入了前几个 chunk，后续 chunk 被静默丢弃。根本原因在于 GridFS 默认不校验写入完整性，且底层 TCP 连接异常未被上层流正确捕获。
实操建议：
- 永远用
await fileStream.finished()等待流彻底结束，不能只依赖uploadFromStream返回就认为完成 - 手动监听
fileStream.on('error', ...)，尤其注意AbortError和NetworkError类错误 - 上传后立即用
bucket.find({ _id: fileId }).toArray()检查实际写入的 chunk 数量是否匹配预期（length/chunkSizeBytes向上取整）
如何设置更小的 chunkSizeBytes 并确保驱动真正生效？
调小分块能显著提升弱网容错率——单个 chunk 传输失败只影响局部，重试成本低。但很多人改了 chunkSizeBytes 却没生效，是因为误在错误位置配置。
关键点：
- 必须在初始化
GridFSBucket时传入，不是在连接字符串或客户端选项里设：const bucket = new GridFSBucket(db, { chunkSizeBytes: 64 * 1024 }); - 注意单位是字节，
64KB（即65536）是弱网下的经验安全值；低于32KB可能因 HTTP 头开销占比升高反而降低吞吐 - 修改后务必检查
fs.chunks集合中新文档的data字段长度，确认是否真实落到目标大小（MongoDB Shell 执行db.fs.chunks.findOne().data.length）
手写重试逻辑时，为什么不能直接重试整个 uploadFromStream？
重复调用 uploadFromStream 会创建全新文件记录，旧的半截文件残留在 fs.files 和 fs.chunks 中，造成存储泄漏和元数据不一致。
正确做法是基于断点续传思想：
- 上传前生成唯一、可复用的
filename或自定义metadata（如哈希+设备ID），用于查询已有上传进度 - 失败后先查
bucket.find({ filename: 'xxx' })，若存在且length ，则用 <code>bucket.openUploadStreamWithId续传，传入原_id和剩余 buffer - 使用
stream.pipeline封装读取逻辑，支持从指定 offset 创建子流（如fs.createReadStream(path, { start: offset })）
重试策略里哪些参数最容易被忽略？
单纯加 try/catch + setTimeout 不足以应对弱网抖动。必须控制三个维度：
-
maxRetries：建议设为3~5，超过后应降级为本地缓存或用户提示，避免无限等待 -
retryDelayMs：必须用指数退避（如Math.pow(2, attempt) * 1000），而非固定值，否则网络拥塞时雪崩式重试 -
timeoutMS：需显式传给uploadFromStream的options，例如{ timeoutMS: 30000 }，否则默认 0（无超时），卡死进程
弱网优化的核心不在“传得更快”，而在“断了能认出来、知道从哪接着干、不把数据库搞脏”。chunk 大小和重试锚点（_id 或 filename）这两个地方一旦配错，后面所有逻辑都白搭。
