在弱网环境下处理文件上传，尤其是使用MongoDB GridFS时，开发者常常会遇到一个令人头疼的“假成功”现象。表面上看，文件上传流程走完了，也拿到了一个ObjectId，但回头一查，文件数据却残缺不全。这背后，往往是默认配置和网络不确定性共同设下的陷阱。
GridFS 上传失败时 uploadFromStream 不抛错但写入不全？
这可以说是弱网场景下最典型的“幽灵”问题了。Node.js驱动的uploadFromStream方法，在网络中断或超时后，有时依然会返回一个看似有效的ObjectId。然而，真相是只有文件的前几个数据块（chunk）被成功写入，后续的数据在传输过程中被静默丢弃了。究其根源，在于GridFS的默认行为并不校验写入的完整性，而且底层TCP连接发生的异常，往往没能被上层的流（Stream）正确捕获并抛出。
要解决这个GridFS上传失败的问题，不能只依赖返回值。这里有几个实操建议：
- 务必使用
await fileStream.finished()来等待数据流彻底结束。仅凭uploadFromStream返回就认为万事大吉，是远远不够的。 - 手动为文件流监听
error事件，特别是要关注AbortError和NetworkError这类错误。 - 上传完成后，立即进行一次验证。通过
bucket.find({ _id: fileId }).toArray()检查实际写入的chunk数量，看是否与理论值（文件length除以chunkSizeBytes后向上取整）匹配。
如何设置更小的 chunkSizeBytes 并确保驱动真正生效？
调小数据块大小，是提升弱网络容错能力的一个有效策略。道理很简单：单个chunk传输失败，只会影响文件的局部，重试的成本和范围都小得多。但很多开发者明明修改了配置，却发现没起作用，问题通常出在配置的位置不对。
关键点在于：
chunkSizeBytes必须在初始化GridFSBucket实例时传入，而不是设置在MongoDB的连接字符串或客户端全局选项里。正确写法是：const bucket = new GridFSBucket(db, { chunkSizeBytes: 64 * 1024 });- 注意单位是字节。将chunk大小设置为64KB（即65536字节）是弱网环境下一个比较稳妥的经验值。设置得过小（比如低于32KB），可能会因为HTTP头等协议开销占比过高，反而降低整体吞吐效率。
- 修改配置后，一定要去数据库里验证一下。可以在MongoDB Shell中执行
db.fs.chunks.findOne().data.length，查看新写入文档的data字段长度，确认是否真的按预期的大小存储了。
手写重试逻辑时，为什么不能直接重试整个 uploadFromStream？
当上传失败，直觉可能是重新调用一次uploadFromStream。但这样做会创建一个全新的文件记录，而之前上传失败残留在fs.files和fs.chunks集合中的“半成品”数据并不会被自动清理。长此以往，不仅会导致存储空间泄漏，还会引发元数据混乱。
正确的思路，是借鉴断点续传的设计：
- 在上传开始前，就生成一个唯一且可复用的标识，比如特定的
filename，或在metadata中存入文件哈希值加设备ID。这个标识用于后续查询上传进度。 - 上传失败后，先通过
bucket.find({ filename: 'xxx' })查询是否已存在部分数据。如果存在且其length小于预期总长度，则应该使用bucket.openUploadStreamWithId方法进行续传，传入原有的_id和剩余的文件数据缓冲区（Buffer）。 - 在读取文件流时，可以利用
stream.pipeline进行封装，并支持从指定的偏移量（offset）开始创建子流，例如使用fs.createReadStream(filePath, { start: offset })。
重试策略里哪些参数最容易被忽略？
要实现健壮的重试机制，仅仅套一个try/catch再加个setTimeout是远远不够的。必须系统地控制好以下三个维度：
maxRetries（最大重试次数）：建议设置在3到5次。超过这个次数后，策略应该降级，比如转为本地缓存或明确提示用户，避免进程陷入无限等待的僵局。retryDelayMs（重试延迟）：切忌使用固定延迟。采用指数退避算法（例如Math.pow(2, attempt) * 1000）才是正道。固定延迟在网络拥塞时，可能引发大量客户端同时重试，造成雪崩效应。timeoutMS（超时时间）：这个参数需要显式地传递给uploadFromStream的options，例如{ timeoutMS: 30000 }。如果不设置，默认值为0，意味着没有超时限制，一旦网络卡死，进程也可能被永久挂起。
说到底，弱网优化的核心目标，并不是追求“传得更快”，而是要确保“断了能及时发现、知道从哪里接着干、并且不污染数据库状态”。数据块大小（chunkSizeBytes）和重试锚点（基于_id或filename的标识）这两处配置，是整个稳定上传逻辑的基石。一旦这里配错了，后面叠加再多复杂的重试和校验逻辑，都可能事倍功半。
