高 Next.js 内存使用率：如何诊断

#确定过程和阶段

记录节点和 Next.js 版本、启动命令和容器或服务限制。下一个开发进程保留不描述下一个启动的编译工具。下次构建期间失败又是另一种情况。

重启前阅读日志。 V8 堆错误和因系统内存限制而终止的进程是不同的信号。保留时间戳、PID 和工作负载。仅 VPS 范围的图表无法将内存归因于 Next.js。

node --version
npm ls next react react-dom
ps -eo pid,ppid,rss,comm --sort=-rss

#比较堆、RSS 和服务内存

process.memoryUsage() 报告的值包括 rss、heapUsed、heapTotal、external 和 arrayBuffers（以字节为单位）。在您正在调查的应用程序进程中调用它，例如通过私有仪器。与它一起运行 node -e 只会测量该新进程。

如果 heapUsed 在收集后下降，而 RSS 保持高位，则不会建立 JavaScript 泄漏。本机分配、缓冲区和分配器行为也值得研究。对于多个进程，还要观察整个服务组。保持诊断端点的私密性。

const timer = setInterval(() => {
  const { rss, heapUsed, external } = process.memoryUsage();
  console.log(JSON.stringify({
    event: "memory-sample",
    pid: process.pid,
    rss, heapUsed, external,
    at: new Date().toISOString()
  }));
}, 10000);
timer.unref();

#重复触发增长的工作负载

选择一条可疑的路由，重复一批相同的请求，然后让服务器解决。每批后记录值。达到稳定状态的初始上升可以反映模块加载或有界缓存。

可比批次后的持续增长需要更仔细的研究。检查每个用户的全局集合、没有过期的缓存、保持活动状态的订阅以及闭包保留的大对象。如果应用程序流响应，则包括取消的请求和中断的连接。

#单独调查构建内存

如果构建失败，请确定阶段：转换、TypeScript 检查或预渲染。为数千个参数生成页面与加载大型编译器依赖项不同。

Next.js 记录了一个实验性的构建内存诊断模式，其限制取决于工作线程和构建引擎。使用前请检查您的版本的适用性。减少分支上的导入或生成批次并比较结果。增加 --max-old-space-size 不会创建 RAM 并且可以使进程更接近 VPS 限制。

#在诊断实例上拍摄快照

堆快照可让您检查对象及其保留路径。比较场景中等效点的捕获，然后调查后续批次后剩余的内容。防止释放的引用比单独的对象大小更重要。

捕获可能会暂停进程并需要大量额外内存。使用具有合适数据的诊断实例。快照可能包含敏感的应用程序信息，因此请确保它们的私密性。不要公开暴露调试端口。

#使用相同的工作负载验证修复

修复后，重复场景、取消和空闲间隔。比较内存、错误和响应时间。较低的堆使用率和吞吐量崩溃可以反映收集权衡，而不是整体改进。

要评估另一个运行时（例如 PRNext），请保留方法和路由。切换运行时不会自动修复无限制的应用程序缓存。首先验证兼容性，然后测量整个服务。

通过内容验证构建 SSR 基准

在项目副本上准备 PRNext 试用版