ECONNRESET在空闲后出现是因服务端或中间设备主动RST断连，非代码错误；Node.js MongoDB驱动需设keepAlive=60000、keepAliveInitialDelay=300000、minPoolSize=1，并禁用socketTimeoutMS（设0）以适配云数据库60–300秒超时。
为什么ECONNRESET总在空闲后出现
这不是代码写错了，而是TCP连接被对端（MongoDB服务端或中间网络设备）主动RST掉了。典型场景是：Node.js客户端建立连接后长时间没发请求，服务端或负载均衡器因超时策略直接断开连接，后续第一次请求就会触发ECONNRESET。它和ECONNREFUSED不同——后者是连不上，前者是“连上了但被踢了”。
keepAlive参数到底该设多少
Node.js MongoDB驱动（v4.13+）默认开启keepAlive，但值太小（30000ms），而云数据库（如Atlas、阿里云MongoDB）的空闲连接超时普遍是60–300秒。必须手动调大：
-
keepAlive：设为60000（60秒），确保心跳包比服务端超时短至少10秒 -
keepAliveInitialDelay：设为300000（5分钟），避免刚连上就发心跳浪费资源 - 同时启用
minPoolSize: 1，防止连接池自动缩容到0后重建连接
示例配置：
wechat-article-extraction-mp-weixin-qq-com news-webpage-cleaning blog-post-parsing metadata-extraction-title-author-date multiple-output-formats-markdown-json-plain-text batch-processing-support
下载
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
const client = new MongoClient(uri, {
keepAlive: 60000,
keepAliveInitialDelay: 300000,
minPoolSize: 1,
maxPoolSize: 10
});
别只改keepAlive，还要关掉socketTimeoutMS
很多开发者调大keepAlive后仍报错，是因为socketTimeoutMS（默认30000ms）在单次操作中途就断开了连接。这个参数和keepAlive无关，它控制的是“一次读/写操作最多等多久”，不是连接保活。
- 如果业务有慢查询或大文档操作，
socketTimeoutMS必须设为0（禁用）或足够大的值（如300000） - 但注意：
serverSelectionTimeoutMS和connectTimeoutMS仍应保持较小（如5000），只影响初始连接阶段 - 云环境尤其要检查：阿里云MongoDB默认强制关闭空闲>60秒的连接，且不响应TCP keepalive包——此时仅靠客户端
keepAlive无效，必须配合服务端白名单+连接池复用
验证是否真生效了
光改配置不验证等于没改。最直接的方式是抓包看TCP层有没有心跳：
- 用
tcpdump -i lo port 27017 -w mongo.pcap在本地MongoDB测试 - 启动应用，等待2分钟，停止抓包，用Wireshark打开，过滤
tcp.len == 0 and tcp.flags.ack == 1 and tcp.flags.push == 0 - 看到周期性（如每60秒）的ACK包，说明
keepAlive已生效 - 若没看到，检查Node.js版本：v18.17+修复了libuv对
SO_KEEPALIVE的设置bug，旧版本即使配了也不起作用
真正麻烦的从来不是参数本身，而是服务端根本无视你的keepalive包——这时候得去翻云厂商文档，确认他们是否透传TCP选项，或者换用连接串里加&maxIdleTimeMS=300000这种服务端感知的保活机制。
