Change Streams 断流退出是默认行为而非 Bug，因 Node.js Readable 流遵循单次消费语义，游标失效即触发 'end' 防止丢事件或重复处理；需手动捕获 'end'、动态持久化 resumeToken 并用 resumeAfter 重建游标，同时调优 maxAwaitTimeMS 等参数提升稳定性。
Change Streams 断流退出不是 Bug，而是默认行为 —— 它在遇到网络抖动、副本集主节点切换、或游标超时后会直接 emit 'end' 并关闭，不重试、不自动恢复。
为什么 watch() 一断就彻底退出，而不是重连？
MongoDB 驱动的 collection.watch() 返回的是一个标准 Node.js Readable 流（非 EventEmitter 模式），它遵循“单次消费”语义：一旦底层游标失效（比如 resumeAfter 对应的 oplog 条目已被滚动清除），驱动就认为该流已不可恢复，直接触发 'end' 事件并销毁内部资源。
这不是设计疏漏，而是为了防止静默丢事件。如果自动重试却没带对 resumeToken，可能跳过中间变更；如果盲目重连又没做幂等，可能重复处理。
- 断流常见触发点：
NetworkTimeoutError、NotPrimaryError、CursorNotFound、MaxTimeMSExpired - 你不会看到
'error'事件 —— 大部分断流是“安静退出”，只发'end'，容易误判为“数据没了” - 用
changeStream.on('close', ...)是无效的，ChangeStream实例本身没有'close'事件
如何实现真正可靠的断点续传？
必须手动捕获 'end'，用上一次事件里的 _id（即 resumeToken）重建游标。不能靠 resumeAfter: lastId 硬写死，得从每个变更事件中动态提取并持久化。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 每次收到
'change'事件，立刻把change._id存到可靠存储（如 Redis 或本地文件），别等批量落库 - 监听
'end'后，读取最新resumeToken，调用collection.watch([], { resumeAfter: token })重启 - 首次启动时若无历史
resumeToken，用{ startAtOperationTime: await db.admin().command({ replSetGetStatus: 1 }) }获取当前 oplog 时间点，避免漏掉启动瞬间的写入 - 别用
fullDocument: 'updateLookup'配合resumeAfter—— 它在断连重连后可能查不到旧文档，导致fullDocument为null
哪些配置会让断流更频繁？
默认参数对长连接并不友好，尤其在跨云或弱网环境下。几个关键选项必须显式调整：
-
maxAwaitTimeMS：默认 1000ms，太短。设为 30000（30秒）可减少因心跳空闲导致的假断连 -
batchSize：默认不设，但设成 1000 可降低单次拉取压力，避免超时 -
collation：如果集合启用了自定义排序规则，watch 时必须显式传入相同collation，否则游标创建失败直接报错退出 - 连接字符串里别加
connectTimeoutMS=1000这类激进超时 —— Change Streams 建立本身就需要时间，超时会卡在初始化阶段
用 Mongoose 还是原生驱动？
用 Mongoose 的 Model.watch() 本质还是调原生 collection.watch()，但有个隐藏坑：Model.watch() 默认会把所有中间件和 Schema 转换逻辑套进去，一旦某个变更事件触发了 Schema 校验失败（比如字段类型突变），整个流会静默终止，且不抛错。
- 生产环境建议绕过 Mongoose，直接用原生驱动的
collection.watch()，控制权更透明 - 如果坚持用 Mongoose，务必在
watch()后加.on('error', console.error)—— 它会捕获 Schema 层抛出的异常，而原生驱动不会 - 别混用：同一个集合上既用
Model.watch()又用db.collection().watch()，两个游标竞争 oplog 位置，互相干扰
最易被忽略的一点：resumeToken 不是永久有效的。oplog 有大小限制（默认 5% 磁盘空间），老的 _id 几小时后就会被覆盖。如果你的应用重启间隔超过 oplog 保留窗口，resumeAfter 必然失败，只能退回到 startAfter 或全量同步兜底 —— 这个边界必须在设计阶段就写进监控告警里。
