VSCode内存高主因是扩展、文件监听和语言服务器，禁用GitLens/ESLint/Python等并配置files.watcherExclude可将内存从1.5GB压至400MB以内；需用Developer: Open Process Explorer查看RSS>300MB的扩展，禁用后必须彻底重启窗口才生效。
VSCode 内存占用高，90% 不是硬件或版本问题，而是扩展、文件监听和语言服务器在后台持续吃资源——关掉 GitLens、ESLint、Python 这几个“内存大户”，再配好 files.watcherExclude，基本能从 1.5GB 压到 400MB 以内。
怎么看哪个扩展在吃内存
别靠猜，直接用 VSCode 自带的进程视图定位：
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入并执行Developer: Open Process Explorer - 重点关注
Extension Host下子项的RSS列：长期 > 300MB 的扩展大概率是元凶 -
ms-vscode.js-debug在调试中临时升高属正常；但长期 > 500MB，要检查断点或source map是否循环加载 - 禁用后必须完全关闭当前窗口再重新打开，否则旧进程仍驻留、内存不释放
为什么 files.watcherExclude 必须配，且不能写错
files.watcherExclude 是防止内存爬升的底线配置，不是“可选优化”。它直接阻止内核级监听句柄注册；而 search.exclude 只影响搜索时跳过哪些路径，监听器早已在后台疯狂分配内存了。
- 必须写进项目根目录的
.vscode/settings.json，而非全局设置 - 通配符必须用双星号：
"**/node_modules/**": true，写成"*/node_modules/*"或"node_modules"无效 - Linux/macOS 用户还需检查系统限制：
cat /proc/sys/fs/inotify/max_user_watches，若低于524288，运行echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches - 如果项目用 pnpm 或 yarn v3+ 的
.pnpmstore，还得额外加"**/.pnpm/**": true
code --disable-gpu 什么时候该用
GPU 加速没有统一答案——它高度依赖你的设备组合。M 系列 Mac 或独显本上关掉反而卡；某些 macOS 外接显示器、旧款 Intel 核显或虚拟机环境下，--enable-gpu 反而引发渲染线程阻塞和内存泄漏。
- 先验证：完全退出 VSCode，在终端运行
code --disable-gpu启动，观察内存峰值是否明显下降 - 若有效，把
"disable-hardware-acceleration": true写进~/Library/Application Support/Code/User/settings.json（macOS）或对应路径 - 若更卡，改用
code --enable-gpu --enable-gpu-rasterization，并确保"workbench.enableExperiments"为false - 注意：
--disable-gpu对渲染线程内存泄漏最敏感，尤其在 macOS Sequoia + Intel Iris Xe 场景下
禁用扩展后内存还不降？你可能没“杀干净”
禁用 ≠ 停止进程。很多扩展注册了 onStartupFinished 或 onLanguage:python，一旦触发就会常驻，直到完全退出 VSCode。
- 禁用后必须重启整个窗口（不是重载窗口），否则
Extension Host进程不会释放旧实例 - 打开终端执行：
ps aux | grep -i "tsserver\|pyright\|python.*language"，确认对应语言服务器 PID 是否消失 - 运行
code --status，看Extension Host下是否还有残留进程名 - 部分扩展（如 GitHub Copilot、Tabnine）会在后台预加载模型，RSS 长期 > 600MB 就该检查是否启用“仅聚焦时激活”
真正卡住的点往往不在“怎么配”，而在“配完有没有彻底重启”和“排除路径有没有写对位置”。files.watcherExclude 写错位置、禁用扩展后只重载窗口不关进程、GPU 参数没写进正确配置路径——这三处最容易被忽略，也最影响效果。
