先运行code --status定位extension host高占用进程（cpu>60%），记下pid后用ps -p [pid] -o comm=（macos/linux）或任务管理器查对应扩展名，再禁用异常扩展并彻底重启vscode窗口。
怎么快速定位吃 CPU 的 Extension Host 进程
VSCode 卡顿时，Extension Host 进程 CPU 占用常超 60%，但它只是“替罪羊”——真正干活的是它加载的某个扩展。不能只看任务管理器里一个 Code Helper (Renderer)，得查子进程。
终端执行 code --status，重点关注输出中 Extension Host 行的 CPU% 和 PID；记下 PID 后，再运行 ps -p [PID] -o comm=（macOS/Linux）或在任务管理器“详细信息”页按 PID 查对应命令名，常见有 pylance、tsserver、eslint-server、rg.exe（ripgrep）。
- 命令面板输入
Developer: Show Running Extensions，按CPU%排序，重点关注esbenp.prettier-vscode、gitlens.gitlens、ms-python.python - 别信“已禁用”——有些扩展禁用后仍残留进程，必须完全关闭窗口再重开才生效
- 禁用后仍高占用？检查
settings.json里是否还留着"eslint.enable": true或"prettier.requireConfig": false这类配置，它们会强制 VSCode 尝试加载插件
为什么禁用 onStartup 扩展必须重启整个窗口
VSCode 的扩展激活机制很实在：注册了 onStartup 的扩展（比如 ESLint、GitLens、Prettier）会在启动瞬间拉起独立 Node.js 子进程，建索引、监听文件、预热语言服务。禁用操作只是阻止下次加载，旧进程不会自动退出。
- 右键扩展 →
Disable (Global)或Disable (Workspace)后，必须彻底关闭当前 VSCode 窗口（包括菜单栏图标），再重新打开项目 - 仅执行
Developer: Reload Window不够——子进程仍在后台跑，ps aux | grep -i "pyright\|tsserver"能验证是否残留 - 对 Python/TS 项目，可手动清理：
kill -9 [PID]，但治标不治本，根源还在激活策略和配置残留
files.watcherExclude 配置写错等于没配
files.watcherExclude 是底层 inotify/fsevents 层级的过滤，比 search.exclude 更关键。但写法极敏感，错一个字符就失效。
- 路径必须用双星号通配：
"**/node_modules/**": true，写成"node_modules"或"*/node_modules/*"都不生效 - 必须加在项目根目录的
.vscode/settings.json中，不是用户级settings.json；改完要关闭并重开工作区，保存文件不触发更新 - Linux 用户额外检查：
cat /proc/sys/fs/inotify/max_user_watches，若低于524288，运行echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches
GPU 加速开关不是二选一，而是分场景验证
--enable-gpu 和 --disable-gpu 效果完全相反，取决于你的硬件组合。M 系列 Mac 上开通常更顺，但 Intel 核显 + 外接显示器可能直接卡死。
- 完全退出 VSCode（包括菜单栏图标），终端执行
code --disable-gpu启动，观察活动监视器里内存峰值和滚动流畅度 - 如果变好，把
"disable-hardware-acceleration": true加进~/Library/Application Support/Code/User/settings.json - 如果更卡，试试
code --enable-gpu --enable-gpu-rasterization，同时确认"workbench.enableExperiments"为false
files.watcherExclude 放错位置、以及 GPU 参数没配合硬件实测——这三处任一出错，优化就白做了。
