微信小程序云开发架构中，Node.js服务端承载着大量云函数调用，而这些函数几乎都要访问云数据库。一旦某处代码获取了连接却迟迟不归还，连接池会逐渐被占满，伴随的数据库连接对象、缓存的结果集无法被GC回收，堆内存也会一路上涨。这类问题往往不会在压测中立刻暴露，而是在线上运行三五天后以OOM或请求超时的形式爆发。本文完整复盘一次连接池泄漏的排查过程，重点演示heapdump快照的采集与分析方法。
一、泄漏现场：从监控数据确认问题性质
故障服务的表现很有代表性：内存曲线呈锯齿状缓慢爬升，每次GC只能回收很小一部分，Full GC的间隔越来越短；同时云开发控制台的数据库监控面板显示活跃连接数单调递增，最终触达连接池上限（默认wx-server-sdk底层连接池通常在几十个连接左右），后续请求全部排队等待，表现为接口大面积超时。
这两个信号叠加，基本可以判断是“连接未归还导致对象被引用链持有”。单纯的对象泄漏只会推高内存，而连接数同步上涨说明泄漏源正是数据库连接相关对象。此时不要急着重启服务掩盖问题，正确的做法是先在内存增长阶段抓取快照，保留现场证据。
确认泄漏的最简单方式是观察“两次GC之间的堆增量”：执行global.gc()手动触发垃圾回收（需以--expose-gc参数启动），如果回收后process.memoryUsage().heapUsed仍持续高于上次基线，说明确有对象被强引用持有，GC无法回收，接下来进入快照分析阶段。
二、heapdump采集：拿到堆内存的“切片”
heapdump是排查Node.js内存问题的经典工具，安装后只需一行require('heapdump')，调用heapdump.writeSnapshot()即可把当前V8堆的完整状态写入一个.heapsnapshot文件。排查泄漏需要对比分析，所以要采集多份快照：建议在服务启动稳定后抓第一份，内存上涨到明显高位并手动GC后再抓第二份，中间可再插入一份作为参照。
const heapdump = require('heapdump');
const path = require('path');
// 定时采集，配合监控阈值手动触发也可以
setInterval(() => {
if (global.gc) global.gc(); // 先GC，剔除可回收对象，让快照更“干净”
const file = path.join('/tmp', `heap-${Date.now()}.heapsnapshot`);
heapdump.writeSnapshot(file, (err, filename) => {
if (err) {
console.error('快照写入失败', err);
return;
}
console.log('快照已保存:', filename);
});
}, 30 * 60 * 1000); // 每30分钟一份，按需调整两点实操经验值得注意。第一，采集前务必手动GC，否则快照里充斥大量临时对象，干扰定位；第二，heapdump写入快照时会阻塞主进程，堆越大阻塞越久（几百MB可能卡顿数秒），线上环境应选择低峰期采集，或通过管理端口接收指令后再触发，避免固定定时器在业务高峰“雪上加霜”。如果服务使用的是较新的Node版本，也可以改用process.report或v8内置的vm.getHeapSnapshot等方案，原理一致。
三、Chrome DevTools对比快照，锁定泄漏对象
拿到两三份.heapsnapshot文件后，打开Chrome DevTools的Memory面板，依次Load加载。核心操作是选中后一份快照，把视图切换为Comparison模式并与前一份对比，按“Size Delta”降序排列，找出两份快照之间数量和体积增量最大的构造函数。
这次排查中，增量榜前列的是几类可疑对象：Db实例、Collection引用游标对象，以及挂在其上的Buffer（驱动返回的结果集缓存）。选中其中一个对象后，DevTools底部的Retainers视图就是定位泄漏源的钥匙——它展示的是“谁持有这个对象导致GC无法回收”的完整引用链。顺着链路向上追溯，会发现这些连接对象被一个statsMap的Map结构以字符串key持有，而这个Map正是代码里用于记录请求耗时统计的全局缓存。
// 泄漏源头：统计缓存把连接句柄当作value存了进去，且永不过期
const statsMap = new Map();
async function queryOrders(db, userId) {
const conn = await db.getConnection();
statsMap.set(`order_query_${userId}`, {
conn, // 问题所在：conn被Map长期持有
startAt: Date.now()
});
const res = await conn.collection('orders')
.where({ userId })
.get();
statsMap.set(`order_query_${userId}`, { startAt: Date.now() }); // 旧key被覆盖，但err分支从未走到这里
conn.release(); // 若上面抛异常，release永远不会执行
return res;
}这段代码集中体现了两类典型泄漏：一是全局Map意外持有连接对象引用，导致连接归还后对象仍不可回收；二是release()没有放在finally中，一旦查询抛出异常（如集合不存在、超时），连接直接“有去无回”。连接池里的连接数量有限，这类错误分支的泄漏往往在正常测试中难以复现，只有线上出现异常请求后才开始累积，这正是问题隐蔽的原因。
四、修复与预防：让资源释放成为惯性
修复分两层。首先是代码层面：所有连接的获取与归还必须配对，把release放进finally块；游标类资源（watch监听、分页游标）要在finally里显式close；确实需要全局缓存的场景，只存纯数据（耗时数字），绝不存连接、游标等资源句柄，或改用WeakMap让它不阻止GC。其次是池层面：给连接配置空闲超时与最大存活时间，避免连接被无限期占用，同时接入池的监控指标，活跃连接数接近上限时及时告警，把问题消灭在累积阶段。
async function queryOrdersFixed(db, userId) {
const conn = await db.getConnection();
try {
return await conn.collection('orders')
.where({ userId })
.get();
} finally {
conn.release(); // 无论成功还是异常，连接必然归还
}
}
// 统计数据与资源句柄解耦，只保留纯数据
const durationStats = new Map();
function recordDuration(key, ms) {
durationStats.set(key, { ms, at: Date.now() });
if (durationStats.size > 1000) {
// 简单的防泄漏兜底：限制缓存规模
const first = durationStats.keys().next().value;
durationStats.delete(first);
}
}修复上线后，连接数曲线恢复平稳，堆内存在每次Full GC后回到基线，泄漏确认消除。回顾整个流程，方法论可以浓缩为三步：监控确认泄漏趋势、heapdump多时点采样、Retainers引用链溯源。掌握这套流程后，无论是云数据库连接、定时器回调还是闭包引用造成的泄漏，都能用同样的思路在半小时内定位到具体代码行，比盲目猜测或重启碰运气可靠得多。