目标：vercel/next.js
问题：vercel/next.js#81161
拉取请求：vercel/next.js#94735
现场实验室：https://github.com/scarab-systems/scarab-field-lab
本次现场测试针对的是 Next.js Turbopack 开发服务器中的一个问题，该问题导致在本地开发期间内存和中央处理器使用率可能大幅攀升。
报告的问题表现范围广泛：
- Turbopack 开发服务器使用了高随机存取存储器和高中央处理器资源
- 路由编译导致中央处理器使用率出现大幅峰值
- 每次路由编译似乎都会增加大量内存占用
- 强制重新加载持续增加内存占用
- 该问题出现在 next dev 命令中
- 复现案例涉及一个包含多个路由的几乎为空的应用程序
这是一个巨大的症状表面。
但是，有限的修复并未尝试解决与该问题相关的每一个 Turbopack 内存、中央处理器、缓存增长或任务驱逐问题。
修复工作集中在一个更狭窄的边界上：
来自被拒绝的生成路径或缓存路径的文件系统监视器事件，不应继续进入 Turbopack 的失效工作流程，仿佛它们是源代码更改一样。
现场实验室记录
此现场测试的公开案例记录可在 Scarab 现场实验室中获取：
https://github.com/scarab-systems/scarab-field-lab
现场实验室是存放公开状态、问题链接、拉取请求链接、验证记录、变更的公开文件、协助披露以及主张边界的地方。
本文是语义现场报告：说明故障的含义、所有权边界在哪里，以及为何修复保持狭窄。
故障形态
可见的故障是 Turbopack 开发服务器中的资源增长。
此类问题容易引发广泛的解释。可能是内存保留问题。可能是任务驱逐问题。可能是缓存增长问题。可能是路由编译问题。可能是依赖行为问题。也可能是开发服务器生命周期问题。
广泛的症状并不自动证明需要进行广泛的修复。
软件开发系统揭示了围绕缓存单一事实来源、缓存新鲜度、共享运行时工件缓存权威性以及 Turbopack 文件系统边界的证据。这将修复方向指向了围绕生成输出和缓存路径的监视器/失效行为。
重要的区别在于：
生成输出和缓存工件并非项目源代码的事实依据。
如果项目文件系统已将生成路径或缓存路径视为被拒绝，那么来自该路径的监视器事件不应继续向失效管道提供数据，仿佛它们代表了有意义的源代码更改。
这是更大性能报告内部的一个较小边界。
边界
这里的边界是：
项目源代码更改
versus
被拒绝的生成输出和缓存工件
Turbopack 需要文件系统监视器，因为源代码更改应使工作失效。
但并非每个原生文件系统事件都代表开发服务器需要关心的源代码更改。
递归平台监视器仍然可以接收来自生成输出和缓存目录的原生事件。即使项目文件系统已知这些路径被拒绝，这种情况也可能发生。
因此，修复问题变为：
如果某个路径已被项目文件系统边界拒绝，来自该路径的监视器事件是否仍应排队进行失效工作？
有限的答案是否定的。
被拒绝的生成/缓存路径应保持在源代码更改失效通道之外。
变更内容
该拉取请求更新了 Turbopack 的文件系统监视器路径处理
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
