VSCode打开大文件后内存不降主因是renderer进程缓存未回收、inotify句柄泄漏及语言服务器残留；需完全退出VSCode、配置files.maxFileSizeMB等阈值、禁用扩展后重载窗口，并在必要时改用less/jq等专用工具。
为什么打开大文件后内存持续上涨，关掉文件也不降？
不是“关掉标签页”就等于释放内存。VS Code 的编辑器实例（renderer process）不会因关闭单个文件而立即回收内存，尤其当该文件曾触发语法高亮、符号索引或语言服务器解析时，相关缓存和 AST 数据仍驻留在 V8 堆中。更隐蔽的是：files.watcherExclude 没配好时，inotify 句柄泄漏会导致内核级资源无法释放，进而拖慢整个进程 GC 效率。
- 必须完全退出 VS Code（不只是关闭窗口），才能清空 renderer 进程堆内存
- 若文件曾被 Python/TypeScript 扩展分析过，
python.analysis.cachePath或tsserver缓存可能仍在后台运行 - macOS 上 Electron 渲染器存在显存未释放 bug，可临时加启动参数
code --disable-gpu验证
哪些设置能真正压住大文件的内存峰值？
光开 editor.largeFileOptimizations 不够——它只禁用折叠和高亮，但默认仍做行号渲染、括号匹配、滚动缓冲区预加载。关键要组合控制三类阈值：
-
files.maxFileSizeMB：设为50，超限文件直接拒绝加载，避免试探性解析 -
files.maxMemoryForLargeFilesMB：设为1024（不是 4096），过高反而让编辑器“硬扛”而非降级 -
editor.maxTokenizationLineLength：设为5000，防止单行超长 JSON/日志卡死 tokenization 线程
注意：editor.largeFileOptimizations 必须为 true，否则后两项无效；且这些配置需写入当前工作区的 .vscode/settings.json，全局设置对多根工作区不生效。
扩展怎么禁才真“杀干净”，不是假装休眠？
右键 Disable 扩展只是停用 UI 功能，很多语言服务器（如 ms-python.python、dbaeumer.vscode-eslint）仍会在 Extension Host 进程里维持连接和缓存。实测有效的做法是：
- 先执行
Developer: Open Process Explorer，找到 RSS > 300MB 的扩展进程，记下 ID（如esbenp.prettier-vscode） - 在命令面板运行
Developer: Reload Window With Extensions Disabled，这会彻底清空 Extension Host - 重启后若需某扩展，再单独启用——别一次性全开，尤其避开
GitLens和Remote - SSH同时启用
特别提醒：ms-vscode.js-debug 在调试结束后常驻内存属正常，但若非调试状态 RSS 仍 > 500MB，大概率是 source map 路径错配导致循环加载，需检查 webpack.config.js 中的 devtool 和 output.sourceMapFilename。
什么时候该放弃 VS Code，换工具？
当文件稳定超过 200MB、且只需查看/搜索/裁剪时，VS Code 已不是最优解。它的文本渲染模型基于 DOM + Canvas，单文件内存占用与文件长度呈近似线性增长，而 vim/neovim 用 mmap + lazy line read，less 甚至只加载当前屏数据。
- 日志分析场景：用
less +G（跳到底）、/pattern（正则搜索）、head -n 10000 big.log > sample.log预处理 - 二进制或 hex 查看：装官方
ms-vscode.hexeditor，它绕过文本解析，内存恒定在 ~80MB - 结构化大数据（JSON/CSV）：用
jq或csvkit命令行过滤，比在编辑器里等高亮更可靠
真正的分水岭不在文件大小，而在操作意图——如果 90% 时间只是 grep、tail、cut，VS Code 就是重武器打蚊子，再怎么调参也难逃内存爬升。
