近日，有开发者提交了一个 VSCode 内存泄露的 issues，该问题造成在某种情形下应用 VSCode 会使运行内存利用率攀升。让人出现意外的是，VSCode 官方却代表不准备处理此问题，从而在小区引起了异议。
2022年十月，有一名开发者发觉了 VSCode 中存有内存泄漏的问题，并在官方库房的 issues 中提交了这个问题：
1. 提前准备一个大文本文档(Citylots.json为〜190MB)：
3. 翻转。
4. 关掉文档。
5. 根据“ Process Explorer”观查运行内存应用状况。
6. 即使大概 30 分鐘后，运行内存利用率依然很高：
即使禁止使用全部拓展后仍然会产生此问题。
接着，这名开发者又注意到这一内存泄漏的 BUG 事实上与大文件不相干，他根据开启好多个 5-10MB 的文本文档再现了这一问题，即使关掉全部编辑软件并等候一会后，也不用实现其他实际操作就可以见到运行内存利用率攀升。该开发者表明，自身碰到这个问题时唯一的解决方法是一旦发觉系统软件内存不够，就只有重新加载 VSCode 对话框，十分不便。
而让人意想不到的是，VSCode 官方对于此事问题的回复居然是无动于衷：
大家已关掉此问题，由于我们不准备在可预料的未来处理此问题。您可以在这里寻找相关大家管理决策全过程的大量详细资料。假如您不同意并觉得此问题尤为重要：大家很愿意聆听并慎重考虑。
VSCode 官方的回应迅速引起了异议，在这里名开发者提交的 issue 下，有很多客户帖子表明自身碰到了一样的问题，也有的甚至是在一年前就遇上了相似的问题，并觉得官方那样的方法对小区客户而言是逃避责任的主要表现。
相隔近2个月，造成这一问题的 VSCode 维护者才总算修补了这一问题：
“ 最先，抱歉发生了这一不正确，大家已增加了修补程序流程。下列是相关不正确和恢复的详细资料：
大家有根据文档的介绍作用(FileBasedRecommendations)，将可监视文字实体模型加上到了编辑软件中，并依据文件扩展名和语言表达强烈推荐后缀名。近期，我对于此事作用实现了改善，以在客户变更文档的言语时给予查验提议(大量详细资料，在这里#102823)。因此，我需要设定窃听器监视文字实体模型的语言表达变更，我本来仅在处理FileBasedRecommendations类时才启用此窃听器，而造成内存泄漏的根本原因恰好是由于在处理完实体模型后窃听器仍在工作中。
大家根据在处理实体模型FileBasedRecommendations(onWillDispose)时处理实体模型窃听器的 has 来处理此问题。”
issues 详细信息：https://github.com/microsoft/vscode/issues/107999
文中转自OSCHINA。
本文文章标题：VSCode 现内存泄漏 BUG，官方处理方法引小区不满意
文中详细地址：https://www.oschina.net/news/121783/vscode-memory-leakage-issues