先用Developer: Show Running Extensions定位内存元凶：RSS＞500MB、Activation Events为onStartup或*、Start Time＞100ms的扩展（如GitLens、ESLint、Python）需优先禁用或调低权重；禁用后必须完全关闭窗口再重开，否则旧进程驻留。
怎么快速定位吃内存的扩展进程
别靠经验猜，直接用 VSCode 自带的实时诊断工具：Developer: Show Running Extensions。按 Cmd+Shift+P（macOS）或 Ctrl+Shift+P（Windows/Linux），输入并执行该命令。
重点关注三列：
-
Activation Events是onStartup或*的扩展——比如ms-python.python、eamodio.gitlens、dbaeumer.vscode-eslint，它们一启动就拉起子进程、扫描依赖、建索引，哪怕你没打开任何 Python/JS 文件 -
Memory列 RSS > 300MB 就该怀疑；长期 > 500MB 基本可确认是元凶 -
Start Time超过 100ms 的，说明初始化开销大，优先考虑禁用
禁用后必须完全关闭当前窗口（不是重载），再重新打开，否则旧 Extension Host 进程仍驻留，内存不释放。
哪些扩展最该禁用或调低权重
高耗扩展不是“要不要用”，而是“要不要现在用”。关键在于控制其激活时机和资源边界：
-
GitLens：默认开启行级 blame 和历史图谱，关掉gitlens.codeLens.enabled和gitlens.hovers.enabled可降 30%–50% 内存；或者直接禁用——VSCode 内置 Git 功能已覆盖日常操作 -
ESLint：全量校验大项目时可能占 800MB+；设"eslint.run": "onType"，并精简"eslint.probe"（例如只留["javascript", "typescript"]） -
ms-python.python（含 Pylance）：类型推导会加载整个依赖树；改用轻量pylsp，或关掉python.analysis.autoSearchPaths，显式指定python.analysis.extraPaths - AI 类扩展（如 GitHub Copilot、Tabnine）：部分版本后台预加载模型，RSS 长期 > 600MB 就该检查是否启用“仅聚焦时激活”
为什么加了 files.watcherExclude 还卡
files.watcherExclude 是防止内存爬升的底线配置，不是“可选优化”。它直接阻止内核级 inotify 监听句柄注册；而 search.exclude 只影响搜索时跳过哪些路径，监听器早已在后台疯狂分配内存了。
必须写进当前工作区的 .vscode/settings.json（不是全局设置），且语法敏感：
- ✅ 正确：
"**/node_modules/**": true - ❌ 静默失败：
"node_modules/**": true或"node_modules/": true
Linux/macOS 用户需检查 /proc/sys/fs/inotify/max_user_watches，若低于 524288，运行：echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches
扩展主机进程本身还能怎么压
VSCode 默认把所有扩展塞进一个 Extension Host 进程，容易因单个扩展泄漏拖垮整体。2026 年新版支持更细粒度控制：
- 在
argv.json（通过Preferences: Configure Runtime Arguments打开）中添加："extensionHostMode": "local-process"，让每个扩展独立进程运行，隔离崩溃与内存泄漏 - 启动时加
--disable-extensions-cache参数：跳过扩展缓存磁盘持久化，强制每次解压到内存——冷启动略慢，但避免缓存损坏导致的长期 RSS 滞留 - 临时调试大文件或性能瓶颈时，用命令面板执行：
Developer: Reload Window With Extensions Disabled，比手动禁用更快
真正难处理的不是单次峰值，而是扩展未清理的 DocumentSelector、重复注册的 onDidChangeTextDocument 监听器、遗留的 WebviewPanel 实例——这些不会出现在设置里，只能靠 Developer: Open Process Explorer + Chrome DevTools 连接 Extension Host 快照分析。
