应直接使用developer: open process explorer定位高cpu/内存插件，重点关注extensionhost下cpu长期>70%或内存突增至300mb+的条目，结合语言模式、files.associations、files.watcherexclude及插件专属大文件配置综合排查。
用 Developer: Open Process Explorer 定位插件 CPU/内存热点
插件本身卡在大文件处理上，往往不是逻辑错误，而是资源被持续占用。直接看进程比猜配置更可靠。
按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS），输入并执行 Developer: Open Process Explorer。重点观察两列：
-
Extension Host进程的 CPU 占用是否长期高于 70% - 各扩展条目右侧的内存值——尤其关注那些在打开大文件后突然飙升到 300MB+ 的扩展
- 如果某个扩展的
Activation Events显示*或onStartup，它大概率一启动就全量加载，没等你打开文件就在后台解析了
检查插件是否绕过 editor.largeFileOptimizations
editor.largeFileOptimizations 只对 plaintext、jsonc 等轻量语言模式生效；一旦插件通过 files.associations 把 .log 映射成 javascript，LSP 就会照常启动，优化直接失效。
实操建议：
- 打开大文件后，看状态栏左下角显示的语言模式 —— 如果是
JavaScript或TypeScript，说明插件已劫持语言关联 - 在工作区
.vscode/settings.json中显式锁定："files.associations": {"*.log": "plaintext"} - 禁用插件的自动语言检测：
"editor.languageDetection": false，防止它覆盖你的设置 - 某些插件（如 Log File Highlighter）会在激活时强制重设语言模式，这类插件必须禁用或换用纯前端高亮方案
验证插件是否触发 files.watcherExclude 失效
插件若监听了 **/logs/** 下的文件变更，而你又没在 files.watcherExclude 里排除它，VSCode 会为每个日志轮转生成的新文件发事件，导致文件监视器线程持续满载。
常见错误现象：
- 打开一个 100MB 的
app.log后，Ctrl+S保存延迟明显，Git 状态刷新变慢 -
Developer: Open Process Explorer中Shared Process内存缓慢上涨
正确做法：
- 在工作区
.vscode/settings.json中确保包含："**/logs/**": true（注意是双星号，不是单星号） - 排除路径必须写在工作区级设置里，用户级设置对插件监听行为无效
- 改完后必须关闭整个窗口再重开，否则 watcher 不会重新初始化
调试插件自身的大文件限制参数
很多插件（如 JSON Tools、Log Viewer）内置了 maxFileSizeMB 类配置，默认可能只有 50MB。超过即降级为只读或直接报错，但不提示。
排查步骤：
- 查插件文档或源码，找类似
files.maxMemoryForLargeFilesMB、json.maxFileSize、logViewer.maxFileSize的配置项 - 在
settings.json中显式提高该值，例如："json.maxFileSize": 512 - 重启 VSCode 后，在命令面板运行插件提供的诊断命令（如
JSON: Show Diagnostics），看输出里是否仍提示“file too large” - 部分插件需同时关掉其 LSP 模式，仅启用文本解析：比如禁用
json.schemas和json.validate
真正难调的点不在配置本身，而在插件和 VSCode 原生机制的交叠区——比如一个插件既监听文件系统，又注册了语言模式，还试图自己做语法树解析。这时候光调一个参数没用，得一层层切掉依赖，确认到底是 watcher、LSP 还是插件自己的 parser 在拖慢。
