VSCode内存高90%非硬件问题，而是默认配置与插件滥用所致；通过Developer: Open Process Explorer定位RSS＞300MB扩展、禁用GitLens/ESLint/Python等并彻底重启窗口，配合在工作区.vscode/settings.json中配置"/node_modules/": true等files.watcherExclude规则，内存可降30%–50%。
VSCode内存占用高，90%不是硬件问题，而是默认配置叠加插件行为导致的资源滥用；关掉几个关键设置 + 精准禁用扩展，内存常可下降30%–50%，且无需重装或换编辑器。
如何快速定位吃内存的扩展进程
别靠猜，直接看 VSCode 自带的进程树。按 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入并执行 Developer: Open Process Explorer。
- 重点关注
Extension Host下子项的Memory列：RSS > 300MB的扩展大概率是元凶 -
ms-vscode.js-debug在调试中临时升高属正常；但长期> 500MB，要检查断点或source map是否循环加载 - 禁用后必须完全关闭当前窗口再重新打开，否则旧进程仍驻留、内存不释放
为什么 files.watcherExclude 比 search.exclude 更关键
files.watcherExclude 是防止内存爬升的底线配置，不是“可选优化”。它直接阻止内核级监听句柄注册；而 search.exclude 只影响搜索时跳过哪些路径，监听器早已在后台疯狂分配内存了。
- 必须在项目根目录的
.vscode/settings.json中配置，而非全局设置 - 推荐值：
"**/node_modules/**": true、"**/dist/**": true、"**/build/**": true、"**/.git/**": true - Linux 用户还需检查：
cat /proc/sys/fs/inotify/max_user_watches，若低于524288，运行echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches
code --disable-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对 Windows/Linux 集成显卡用户效果通常最显著
WSL2 场景下 VSCode 内存为何特别高
VSCode Remote-WSL 启动的 vscode-server 进程本身就要 300–600MB，加上 WSL2 虚拟机默认动态分配内存（最高可达物理内存的 80%），文件监视器又在 Linux 侧重复监听，三重叠加极易突破 1.5GB。
- 必须在 Windows 用户主目录下创建
.wslconfig文件，内容如：[wsl2] memory=4GB swap=1GB
- 保存后在 PowerShell 执行
wsl --shutdown，再重启 WSL 发行版 - 同时在 WSL 内项目根目录配置
files.watcherExclude，避免node_modules被双重监听 - 禁用
Remote-WSL自动启动的非必要服务，比如关闭remote.WSL.startOnLogin
真正容易被忽略的是：files.watcherExclude 必须写在工作区级 .vscode/settings.json 里才生效，全局设置无效；而 WSL2 场景下，Windows 和 Linux 两侧的监听机制会叠加，单边优化没用。
