trace.md → distill → skill.md

**User**: 线上一个 Node 小服务跑两三天内存就涨到 1.5G
然后被 OOM 杀掉。帮我找到泄漏根因并修掉，
做完了的标准是：压测下内存曲线平稳。

**Assistant**: 先写一个最小复现：带请求缓存的 HTTP 服务，
cache 有 100ms TTL 清理，另有一个 history 数组做审计。

$ MODE=load node server.js

真实输出（8 秒压测）：
{"rss":98, "history":807,  "cacheSize":87}
{"rss":121,"history":1634, "cacheSize":75}
{"rss":129,"history":3296, "cacheSize":87}
{"rss":130,"history":6664, "cacheSize":81}
{"rss":130,"history":10021,"cacheSize":83}

**User**: cache 不是有 TTL 吗，怎么还涨内存？

**Assistant**: 看数据分流：
- cacheSize 稳定在 ~85 → TTL 清理有效，cache 排除
- history 每秒 +1000 无界增长 → 真凶是审计数组

坑：直觉先怀疑 cache，但它实测平稳；
真凶是看起来"无害"的 history 数组。

**User**: 那怎么修？

**Assistant**: 审计只需近期记录 → 环形缓冲：

$ const MAX_HISTORY = 1000;
$ if (history.length > 1000) history.shift();

重跑时踩坑：Error: listen EADDRINUSE
上一个进程没杀干净。

$ lsof -ti:3000 | xargs kill
$ MODE=load node server.js

修复后真实输出：
{"rss":99, "history":1000,"cacheSize":85}
{"rss":112,"history":1000,"cacheSize":74}
{"rss":117,"history":1000,"cacheSize":82}
{"rss":115,"history":1000,"cacheSize":81}

验收通过：压测下内存不再持续上涨。

---
name: node-memory-leak
description: 当 Node 服务内存持续上涨 / 被 OOM 杀掉 /
定时任务越来越慢时，定位泄漏根因并修复。
---

# node-memory-leak

## 目标 / 成功判据
- 定位内存泄漏根因并修复
- 验收标准：压测下内存曲线平稳（rss 涨到阈值后持平）

## 触发条件
- Node 服务内存持续上涨 / 被 OOM 杀掉 / 定时任务越来越慢

## SOP
1. 构造最小复现：嫌疑点（如缓存、数组）+ 每秒打印
   process.memoryUsage 与嫌疑数据结构长度
2. 压测运行，观察哪一项无界增长——增长者即泄漏源
3. 修复后重新压测，确认内存曲线平稳才收工

## 决策点
- 嫌疑结构长度无界增长 → 它是泄漏源
- 平稳 → 排除，查下一个
- 数据须全量保留 → 落盘日志
- 仅需近期 → 环形缓冲固定容量

## 硬约束（坑与修正）
- 直觉先怀疑缓存，但它有 TTL 清理、实测平稳；
  真凶是无界审计数组
  修正: 无界数组是最常见泄漏形态，
  优先排查所有只 push 不清的数组/Map
- 重跑报 EADDRINUSE，残留进程占端口
  修正: 按端口查 PID 再杀：
  lsof -ti:{{port}} | xargs kill
- 不看数据直接"优化"直觉嫌疑点
  修正: 禁止。修复前必须量化确认泄漏源

## 可复用资产
- server.js（最小复现脚本模板）