--expose-gc 仅暴露 global.gc() 供手动触发 GC，不自动回收，仅限本地调试；生产环境禁用，真正排查内存泄漏需结合内存快照对比与自动化监控。
在 Node.js 服务端中，--expose-gc 本身**不会自动触发垃圾回收**，它只是将 V8 的 gc() 全局函数暴露给 JavaScript 层，让你**手动调用**（仅限本地开发/调试环境）。生产环境严禁启用，且无法用于“自动排查”内存泄漏——它只是辅助工具，真正排查需结合内存快照和增长趋势分析。
启用 --expose-gc 并手动触发 GC
启动服务时添加参数：
node --expose-gc server.js
在代码中（如某个 HTTP 路由或定时器里）可安全调用：
-
global.gc()—— 强制执行一次完整的垃圾回收（仅当启用了--expose-gc时存在） - 注意：该函数是同步阻塞的，会暂停 JS 执行，**绝不能在生产请求路径中调用**
- 常见写法示例（仅调试用）：
if (global.gc) {
global.gc();
console.log('GC forced, heapUsed:', process.memoryUsage().heapUsed);
}
配合 memoryUsage() 观察内存变化
单纯触发 GC 不够，要对比 GC 前后的内存指标，看是否“回收不干净”：
-
process.memoryUsage().heapUsed：当前堆中已分配且未释放的字节数 -
process.memoryUsage().heapTotal：V8 堆总大小（含空闲空间） - 建议在相同操作前后（如反复调用某接口 10 次），每次调用前
gc()，再记录heapUsed，若持续上涨，说明有对象未被释放
生成 Heap Snapshot 定位泄漏源头
手动 GC 只能验证“有没有泄漏”，定位“谁泄漏”必须靠快照：
- 使用
node --inspect server.js启动（无需--expose-gc） - 打开 Chrome 浏览器访问
chrome://inspect→ 连接你的 Node 进程 - 切换到 Memory 面板 → 选择 “Heap snapshot” → 点击 “Take snapshot”
- 重复操作（如模拟请求）→ 再拍一张 → 使用 “Comparison” 视图对比，重点关注 Delta > 0 且数量持续增长的构造函数（如
Closure、Array、自定义类）
更实用的自动化监控方式（推荐替代手动 GC）
比频繁手动调用 gc() 更有效的是监听内存阈值并告警：
- 用
process.memoryUsage()定期采样，比如每 10 秒检查heapUsed是否超过阈值（如 300MB） - 结合
heapdump模块（npm install heapdump）在超限时自动生成快照：
const heapdump = require('heapdump');
setInterval(() => {
const used = process.memoryUsage().heapUsed;
if (used > 300 * 1024 * 1024) {
const filename = heapdump.writeSnapshot();
console.log('Heap snapshot written:', filename);
}
}, 10000);
这样既避免了阻塞请求，又能捕获真实泄漏现场。
