Session被杀主因是云平台连接层误断活跃连接，而非sessionTimeoutMinutes过小；该参数仅控制空闲会话回收，事务中持续交互不触发其生效。
Session 被杀不是因为 sessionTimeoutMinutes 设置太小
事务执行中报 session is not valid 或 MongoClient.startSession failed，很多人第一反应是去调大 sessionTimeoutMinutes——这基本是白忙。这个参数控制的是「空闲会话」在服务端自动清理的时限（默认 30 分钟），而事务中的 Session 是活跃状态，根本不会被它触发回收。
真正杀死事务 Session 的，是云平台连接层对「长连接存活状态」的误判或主动中断。比如阿里云 DTS 后台开启的「空闲连接自动释放」、腾讯云 TDMQ 的连接池健康检查超时、华为云 DDS 的 LB 会话老化策略，都会在事务进行到一半时，把底层 TCP 连接静默断开，导致驱动感知不到，但下次发命令时才发现 Session 已失效。
-
sessionTimeoutMinutes只影响 没任何操作 的会话，事务内持续有命令交互，不在此范围内 - 该参数需重启
mongod才生效，生产环境无法热调，也不解决实时中断问题 - 调大它反而可能掩盖真实连接治理问题，让故障更难定位
怎么确认是不是连接层在“杀”Session
最直接的办法是绕过所有中间件，用 mongosh 直连主节点地址（不是集群 VIP，不是只读域名），手动跑一次完整事务流程：
use test
session = db.getMongo().startSession()
session.startTransaction()
session.getDatabase("test").getCollection("orders").insertOne({ status: "pending" })
session.commitTransaction()
如果这一步成功，但你的应用代码失败，问题 100% 出在客户端连接配置或云平台代理上。
- 检查连接字符串是否用了
xxx-readonly.mongodb.rds.aliyuncs.com这类只读地址——事务必须直连主节点 - 确认驱动未启用
maxIdleTimeMS（Node.js）或设置了过短的连接空闲回收（Java） - 在云控制台关闭「连接池自动释放」「空闲连接回收」等开关，这类功能常把活跃 Session 当空闲连接干掉
Node.js 驱动里 session 状态断裂的典型表现
Node.js 的 mongodb 驱动对 Session 生命周期管理较敏感，尤其在连接复用或 client 重建场景下容易丢状态：
- 调用
client.close()后又新建client，但旧session对象仍被复用 → 报session is not valid - 全局设置了
readPreference: 'secondary'，事务内操作被路由到从节点 →CommandNotFound: 'startSession' - 使用了连接池自动扩缩容（如 PM2 cluster 模式下多个进程共享 client），但 Session 不跨进程传递 → 某个进程 commit 时 session 已在另一进程被销毁
正确做法是：每个事务生命周期内，session 必须由同一个 client 实例创建并持有；避免在事务中途重建 client；禁用全局 readPreference，改用 session.withTransaction() 自动保障一致性。
事务提交前主节点切换导致 Session 失效
这是最容易被忽略的「隐形杀手」：事务开始时连的是主节点 A，提交前 A 宕机，B 成为新主，但驱动还没完成拓扑刷新，仍往 A 发 commitTransaction —— 此时 A 已不接受写请求，返回 NotPrimaryNoSecondaryOk，Session 在服务端被强制终止。
- 老版本驱动（如
mongodb@4.13之前）拓扑刷新周期默认 30 秒，远慢于云平台秒级故障转移 - 分片集群中，coordinator shard 切换主节点后，各分片的 logical session cache 可能不同步，导致
txnNumber不一致 - 临时缓解：调小
logicalSessionCacheRefreshPeriodMS到 30000，并滚动重启分片；长期方案是升级驱动至@5.1+，它支持更快的 topology monitoring
Session 不是凭空消失的，它总在某个环节被切断——要么连接被代理劫持，要么驱动没跟上拓扑变化，要么你无意中复用了已失效的 session 对象。盯住这三个点，比调参数管用得多。
