VSCode 内存高、启动慢主因是扩展和文件监听，可通过 Developer: Show Running Extensions 识别 onStartup 激活的扩展并按需禁用；排除 node_modules 等目录监听、调整 GPU 加速及清理 WorkspaceStorage 缓存可显著优化性能。
VSCode 内存高、启动慢，90% 是扩展和文件监听在拖后腿，不是机器不行，也不是必须换编辑器。
怎么快速识别吃内存的扩展
打开命令面板 Cmd+Shift+P → 输入并执行 Developer: Show Running Extensions，它只列出当前正在后台运行的扩展，比单纯看“已启用”更真实。重点关注那些 Activation Events 含 onStartup 或 * 的扩展——比如 ESLint、Prettier、GitLens、Python（Pylance）、PHP Intelephense，它们一启动就拉起独立进程、扫描文件、预建索引，哪怕你没开一个 .py 或 .php 文件。
禁用策略建议：
- 全局禁用非当前项目必需的：右键扩展 →
Disable (Global) - 只在某项目用的：选
Disable (Workspace)，避免影响其他项目 - 对语言服务器类扩展（如
ms-python.python），可进其设置页关掉python.analysis.autoSearchPaths，改用python.analysis.extraPaths显式指定路径
为什么 node_modules 会让 VSCode 卡死
VSCode 默认用 chokidar（macOS/Linux）或 fsevents（macOS）监听整个工作区，一旦遇到 node_modules 这种动辄数万文件的目录，内核 inotify 句柄会迅速耗尽，I/O 飙升，连保存、搜索、切换标签都卡顿。
解决方法是在项目根目录的 .vscode/settings.json 中写死排除：
{
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/**": true
},
"search.exclude": {
"**/node_modules": true,
"**/dist": true,
"**/build": true
}
}
Linux 用户额外检查：cat /proc/sys/fs/inotify/max_user_watches，若低于 524288，运行 echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches。
GPU 加速该开还是该关
这不是非黑即白的选择：M 系列 Mac 或独显本上，--enable-gpu 能让滚动、缩放、多标签更顺；但某些 macOS 外接显示器组合、虚拟机、旧款 Intel 核显下，--enable-gpu 反而引发渲染线程阻塞和内存泄漏。
验证方法很直接：
- 完全退出 VSCode（包括菜单栏图标）
- 终端执行
code --disable-gpu启动，观察启动速度与活动监视器中内存峰值是否下降 - 若效果好，把
"disable-hardware-acceleration": true加进~/Library/Application Support/Code/User/settings.json - 若更卡，改用
code --enable-gpu --enable-gpu-rasterization，并确保"workbench.enableExperiments"为false
容易被忽略的缓存残留点
损坏的窗口状态（分屏尺寸、折叠代码块、终端历史）会被持久化到 WorkspaceStorage，主进程加载时反复解析异常结构，触发内存重复分配。
操作很简单但常被跳过：
- 关闭所有 VSCode 窗口
- 访达前往
~/Library/Application Support/Code/WorkspaceStorage - 把整个文件夹拖到桌面（别删，先备份）
- 重新打开 VSCode → 它会重建干净的缓存结构
这个动作不改变你的设置或扩展，但能清掉大量隐性内存泄漏源头——尤其当你频繁切换项目、重开窗口、或升级 VSCode 后出现莫名卡顿，值得优先试。
