Serverless中无法长期持有数据库连接，导致事务失败的根本原因是生命周期错配：MongoDB事务依赖稳定的ClientSession和未关闭的MongoClient连接，而云函数执行结束后会销毁上下文。
Serverless 环境下无法长期持有数据库连接，直接在函数内开启事务会失败——session.startTransaction() 必须在连接存活期内调用，而云函数冷启动时连接已断，热执行中连接又可能被平台回收或复用污染。
为什么 Serverless 中 startTransaction 总抛 MongoNetworkError 或 TopologyClosedError
根本原因不是代码写错，而是生命周期错配：MongoDB 事务依赖一个稳定的 ClientSession 实例，该实例必须绑定到未关闭的 MongoClient 连接上。Serverless 平台（如 AWS Lambda、阿里云函数）会在函数执行结束后主动销毁运行上下文，包括所有未显式清理的 socket 和 session。
- 冷启动时新建
MongoClient，但未复用或未正确缓存，导致每次调用都新建连接池，触发maxConnecting限制或超时 - 热执行中复用旧
ClientSession，但其底层连接已被平台静默关闭，再调用commitTransaction()就报TopologyClosedError - 事务跨函数调用（如分步提交）完全不可行——Serverless 函数之间无共享内存或持久上下文
用 client.withSession() 替代手动管理 session
Node.js 驱动 4.0+ 提供了安全封装：它确保 session 在回调执行期间自动创建、使用、结束，且不依赖外部变量生命周期。这是唯一推荐的 Serverless 事务写法。
- 不要自己调用
client.startSession()后保存到闭包或全局变量 - 必须把全部事务逻辑写进
withSession的回调里，包括所有collection.insertOne()、updateMany()等操作 - 回调中抛出异常会自动触发
abortTransaction()；正常返回则自动commitTransaction()
exports.handler = async (event) => {
const client = new MongoClient(uri, { maxPoolSize: 10 });
try {
await client.connect(); // 每次函数执行都 connect，但连接池可复用
return await client.withSession(async (session) => {
// 所有事务操作必须在此回调内完成
const coll = client.db('mydb').collection('orders');
await coll.insertOne({ status: 'pending' }, { session });
await coll.updateOne({ _id: ... }, { $set: { status: 'confirmed' } }, { session });
// ✅ 自动 commit
});
} finally {
await client.close(); // 显式 close 防止 socket 泄漏
}
};
连接池参数必须显式调小，否则快速耗尽数据库连接数
Serverless 场景下并发函数实例数可能远超预期（尤其突发流量），默认 maxPoolSize: 100 会让每个函数实例独占最多 100 个连接，极易打爆 MongoDB 的 maxConnections 限制（Atlas 免费版仅 500）。
- 将
maxPoolSize设为 2–5，配合函数内存设为 512MB+ 提升单实例处理能力 - 必须设置
minPoolSize: 0，避免空闲函数实例维持无效连接 - 添加
maxIdleTimeMS: 60000（1 分钟），让空闲连接及时释放，防止 NAT 超时断连 - 禁用
retryWrites: true—— Serverless 中重试可能跨实例，破坏事务语义
真正需要事务的场景极少，优先用单文档原子性替代
MongoDB 单文档操作天然原子，90% 的「多表一致性」需求（如扣库存+生成订单）可通过嵌入式结构或两阶段提交模式规避事务开销。Serverless 下事务应是最后手段。
- 如果业务允许最终一致，用消息队列解耦 + 补偿任务，比事务更可靠
- 若必须强一致，检查是否真跨集合：同一集合内多个文档更新仍可借
bulkWrite({ ordered: false })+ 唯一索引模拟原子性 - 事务内禁止任何 I/O、HTTP 请求或长耗时计算——超时（Lambda 默认 15 秒）会导致自动 abort，且无法回滚已执行部分
最容易被忽略的是：Serverless 环境中事务的「隔离性」其实很弱。你无法控制其他并发函数是否读到未提交数据，因为 readConcern: "snapshot" 在无状态函数里无法保证会话级快照延续。别假设它像传统服务端那样工作。
