Disable (Workspace)更有效，因它让VSCode在该工作区启动时彻底跳过插件激活逻辑，避免Extension Host拉起冗余服务；而全局禁用仅阻止新窗口加载，旧工作区已激活的插件进程仍驻留。
为什么Disable (Workspace)比全局禁用更有效
全局禁用插件（Disable）只阻止插件在新窗口加载，但旧工作区里已激活的插件进程仍驻留——比如你在项目A启用了gitlens，切到项目B后即使全局禁用，gitlens的进程还在跑。只有Disable (Workspace)才能让VSCode在该工作区启动时彻底跳过激活逻辑，避免Extension Host拉起冗余服务。
关键点在于：VSCode插件按工作区注册监听和语言服务器，不是按“装没装”决定是否运行。一个插件只要被某个工作区触发过，它的进程就会常驻，直到那个工作区窗口完全关闭。
- 必须通过命令面板执行
Extensions: Disable Extension in This Workspace，或在扩展列表顶部切换到Workspace标签页操作 - 右键菜单里的
Disable默认是全局，容易误操作 -
.vscode/extensions.json中写入"recommendations"会覆盖禁用状态，打开文件夹时自动弹窗推荐安装
哪些插件必须按工作区禁用
这几类插件一旦激活就拉起独立语言服务器或后台索引，且不随工作区切换释放资源：
-
ms-python.python（含Pylance）：启动后常驻1.2GB+，建议在非Python项目中直接Disable (Workspace) -
dbaeumer.vscode-eslint：若项目无.eslintrc.js，它会扫描整个node_modules，内存轻松破800MB -
eamodio.gitlens：默认开启行级blame和历史图谱，gitlens.codeLens.enabled和gitlens.hovers.enabled建议关掉 -
github.copilot或alibaba.aliyun-lingma：不同工作区索引互不共享，重复加载极易爆内存
禁用后别信UI灰显状态——得看真实进程是否退出。运行code --status记下Extension Host PID，再用ps -p [pid] -o args=确认命令行里不含pyright、tsserver、gitlens等关键词。
禁用后内存不降？检查这三处残留配置
插件禁用后内存照涨，大概率是配置文件悄悄复活了它：
-
.vscode/settings.json里还留着"eslint.enable": true或"python.defaultInterpreterPath"这类开关，VSCode会尝试加载对应插件来解析配置 -
keybindings.json绑定了插件快捷键（如extension.prettier.format），启动时强制拉起插件 -
.vscode/extensions.json中"recommendations"包含已被禁用的插件名，一打开该文件夹就弹窗提示安装
最稳妥的做法：禁用插件后，手动删掉settings.json里所有该插件相关的配置项；用code --list-extensions核对是否真被排除；打开工作区前先清空extensions.json中的recommendations数组。
files.watcherExclude配错等于白配
files.watcherExclude是防内核级内存泄漏的关键，但配错路径根本无效：
- 必须写进当前工作区的
.vscode/settings.json，全局设置不生效 - 通配符必须用
"**/node_modules/**"，写成"node_modules"或"*/node_modules/*"会被忽略 - Linux/macOS用户要检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288会导致watcher静默失败并反复重试 - 软链接指向
node_modules时，还得加"search.followSymlinks": false
验证是否生效：打开终端运行ps aux | grep code-watcher，如果输出里仍有大量inotify相关进程，说明排除规则没命中——此时得回看路径是否拼错，或是否存在嵌套node_modules未被**覆盖。
