我们公司部署于香港服务器的一项 Next.js SSR 项目却在上线后频繁遭遇内存暴涨，甚至引发 Node.js 进程崩溃。本文将通过真实案例，详尽还原问题发现、排查过程与最终解决方案，以帮助开发者应对类似挑战。
这个项目为跨境电商的产品展示站点，使用 Next.js 构建，开启 SSR 模式，通过 API 获取动态内容，在香港的阿里云轻量应用服务器（2 核 4G 内存）上部署，Node.js 版本为 v18.16.1，运行方式采用 PM2 进行进程管理。
技术栈概览：
- 前端框架：Next.js v13（App Router）
- 后端接口：调用 RESTful API（每日更新商品数据）
- SSR 渲染：通过 getServerSideProps 获取数据
- 部署方式：Docker + PM2
- 操作系统：Ubuntu 22.04 LTS
- 内存监控工具：htop、pm2 monit、heapdump
项目部署初期运行正常，但在高并发访问下，香港服务器内存使用率迅速上涨，最终被系统 OOM Killer 杀死 Node.js 进程。
现象表现：
- 初始内存使用仅约 200MB；
- 高峰期内存飙升至 3.5GB（接近系统上限）；
- 访问高频页面加载变慢，响应时间增长；
- PM2 日志中无明显报错，但系统日志显示内存不足；
- 重启服务后问题暂时缓解，但很快重现。
故障初步排查
1. 内存泄漏初步排查
使用 pm2 monit 观察内存趋势，发现内存使用持续线性上升，未见明显回落，怀疑为内存泄漏。采用 heapdump 模块配合 Chrome DevTools 排查：
import heapdump from 'heapdump';
setInterval(() => {
heapdump.writeSnapshot(`/app/dumps/heap-${Date.now()}.heapsnapshot`);
}, 1800000);
通过分析 snapshot，发现大量缓存数据未被释放，指向一个名为 cacheMap 的全局对象，属于项目中对 fetch 数据做缓存的自定义模块。
深入定位问题
2. SSR 缓存机制问题
在 getServerSideProps 中，开发者使用了全局对象进行手动缓存优化：
const cacheMap = new Map();
export async function getServerSideProps(context) {
const key = context.query.id;
if (cacheMap.has(key)) {
return { props: { data: cacheMap.get(key) } };
}
const res = await fetch(`https://api.example.com/item?id=${key}`);
const data = await res.json();
cacheMap.set(key, data);
return { props: { data } };
}
由于该缓存未设置失效机制，且运行于单个长生命周期 Node.js 实例中，导致 Map 持续增长，占用大量内存。
解决方案
1. 引入 LRU 缓存替代无界 Map
替换全局 Map 为 LRU 缓存，限制缓存数量并自动清除旧数据，使用 lru-cache 模块：
import LRU from 'lru-cache';
const cache = new LRU({
max: 500, // 最大缓存 500 条
ttl: 1000 * 60 * 10 // 每条数据缓存 10 分钟
});
export async function getServerSideProps(context) {
const key = context.query.id;
if (cache.has(key)) {
return { props: { data: cache.get(key) } };
}
const res = await fetch(`https://api.example.com/item?id=${key}`);
const data = await res.json();
cache.set(key, data);
return { props: { data } };
}
2. 优化 Node.js 启动参数
通过观察发现 Node.js 默认的内存限制为约 1.5GB，可以适当扩展（具体视服务器可用内存而定）：
node --max-old-space-size=3072 index.js
在 pm2.config.js 中设置启动参数：
module.exports = {
apps: [{
name: 'next-app',
script: './index.js',
node_args: '--max-old-space-size=3072'
}]
};
3. 分析 GC 行为
使用 –trace-gc 参数启动 Node.js 进程：
node --trace-gc index.js
观察 GC 日志后确认：内存增长过快导致频繁 GC，但无法及时回收无用对象，进一步验证缓存问题是根源。
后续优化建议
SSR 缓存建议统一封装，采用模块隔离并监控命中率；
- 利用 Redis 等外部缓存方案避免内存占用过高；
- 页面层面引入静态生成（SSG）和 ISR 混合模式，降低实时 SSR 负担；
- 引入 Prometheus + Grafana 做内存与性能监控；
- 定期进行 heap snapshot 对比分析，检查泄漏源头。
本次内存暴涨问题源于对SSR缓存机制理解不足，使用了无界增长的内存结构。在长生命周期服务中，任何“全局缓存”都必须设有边界。通过引入 LRU 缓存、调整 Node.js 内存限制并优化服务结构，问题得到有效解决。
