# PRNext 耐力测试：两个小时和 1,738 编辑

快速编辑很有用。在数百次更改后仍保持可靠的开发会话同样重要。我们运行了两个小时的冻结 PRNext 0.1.17 开发快照来检查更长的工作流程。

目的是找到丢失的状态、损坏的恢复、中断的流和不受控制的资源增长。这是具有定义的工作负载的稳定性测试，而不是与 Next.js 的新速度比较。

## 具有真实编辑和真实浏览器的会话

运行持续了 7,201 秒并应用了 1,738 JavaScript 和 CSS 编辑。四个 Chromium 选项卡使用 App Router 和 Pages Router 固定装置。故意的语法错误中断了序列 28 次以测试恢复。

浏览器检查保留了文档标记和组件状态，而不是考虑 HTTP 200 响应就足够了。工作负载还检查流式响应顺序以及响应后访问缓存的后台工作。

该场景还执行了 175 服务器操作调用。每个响应都必须属于预期的应用程序生成，而不仅仅是在传输层取得成功。修复源后，语法恢复必须将页面恢复为可用输出，而不重置不相关选项卡中的状态。

四个浏览器选项卡，保留文档和组件状态。 28 在强制语法错误后恢复。 174 流媒体和 174 后台/缓存检查。浏览器线束记录的页面错误为零。

## 衡量服务树，而不仅仅是一个进程

采样的进程树包括 Node.js、esbuild 和本机 Rust 服务。其峰值比例集大小为 536.51 MiB。定义的稳态窗口之间的增长为 59.05 MiB，最多有十个采样过程。

这些读数保持在测试的资源预算范围内。它们是对该夹具、取样方法和机器的观察；它们不是通用的内存要求，也不是不存在泄漏的证据。

仅计算本机服务会隐藏 JavaScript 工作线程和编译器助手的成本。比例集大小对共享内存的解释也与驻留集读数的总和不同。因此，当另一次运行与这些数字进行比较时，峰值和稳态增长属于他们的采样方法。

## 明确测试快照

在添加最终的 .mts/.cts 框架边界防护之前，两个小时的运行使用了冻结快照。其编辑源是 JavaScript 和 JSX。最后的守卫接受了单独的回归、包装和平台检查，以及较短的四片烟道。

辅助文件系统保留监视器也有 25-minute 采样间隙。主要浏览器和内存检查仍在继续。在报告中保留这些限制比呈现从未测量过的不间断结果更重要。

快照之间的区别对于安全敏感的修复非常重要。后来的边界守卫有自己的传递回归和生命周期证据，但这些检查无法追溯更改运行了两个小时的源。保留这两个记录可以准确地了解每个结果所确定的内容。

## 我们从结果中得到什么

在这个 Linux x64 工作负载上，重复编辑、恢复和资源预算仍然存在。 Windows x64 获得单独的打包、生命周期和浏览器验证。单独的浏览器回归还验证匿名默认组件和新服务器操作响应的状态保留。

它不会验证 macOS 或 ARM64、取代特定于应用程序的测试或显示相对于 Next.js 的新性能优势。这些是具有单独测量的单独问题。

对于特定于应用程序的检查，请保持几个代表性页面打开，在编辑之前与它们交互，并包括故意的语法错误，然后进行修复。观察浏览器错误和服务进程树以及构建持续时间。这测试了工作的连续性，而不是将整个会话减少到最快的刷新速度。

[如何对 React SSR 性能进行基准测试](/zh/blog/benchmark-react-ssr)

[高 Next.js 内存使用率：如何诊断](/zh/blog/diagnose-nextjs-memory-usage)

[PRNext 0.1.18 与 Next.js：CPU、RAM 和睡眠](/zh/blog/prnext-vs-nextjs-vps-benchmarks)

已发表: 2026-10-24

修改的: 2026-10-25

作者: PRNext

---

语言: zh-Hans

Canonical: https://prnext.dev/zh/blog/two-hours-of-development-testing

Index: https://prnext.dev/llms.txt