禁用（工作区）不终止插件进程，仅ui灰化；真正隔离需用profile或dev containers：profile隔离配置但共享extension host，dev containers则彻底沙盒化运行时。
Disable (Workspace) 不等于插件真退出
点了“禁用（工作区）”后插件图标变灰，但内存不降、进程还在跑——这不是 UI 欺骗你，是 VSCode 插件机制本身的设计：只要 Extension Host 进程没杀，已激活的插件（比如 gitlens、pyright、tsserver）就常驻内存，不管你在哪个工作区。
常见错误现象：
- 切换项目后 GitLens 仍在后台扫描历史，CPU 占用高
-
code --status显示 Extension Host PID 未变，ps -p [pid] -o args=仍含目标插件名 - 执行
Developer: Reload Window后插件功能照常响应
必须做的三件事：
- 在扩展面板顶部切到
Workspace标签页（不是Global），再点齿轮 →Disable (Workspace) - 彻底关闭当前窗口（macOS 要右键菜单栏图标 →
Quit，不能只关窗） - 用终端执行
code .重新打开该文件夹，不要双击打开
Profile 是唯一真正隔离插件的方案
VSCode 1.84+ 内置的 Profile 功能，才是解决“不同项目用不同插件”的正解。它不是推荐、不是覆盖，而是为每个 Profile 维护一套独立的已安装扩展列表、设置、快捷键和代码片段——相当于开了多个互不通信的 VSCode 实例。
创建与绑定流程：
- 命令面板输入
Profile: Create Profile，命名如frontend-react或backend-python - 打开目标项目文件夹 → 左下角点击 Profile 名 →
Apply Profile to Folder - 下次直接用 Finder / Explorer 打开该文件夹，VSCode 自动加载对应 Profile
注意：
-
.vscode/extensions.json只能推荐插件，不能强制卸载或禁用已装插件 - Profile 不同步扩展安装状态，首次应用需手动启用所需插件（如
ms-python.python） - Profile 之间完全隔离：一个 Profile 里装的
esbenp.prettier-vscode，另一个 Profile 看不见
哪些插件必须按工作区管理
这几类插件最容易跨工作区泄漏内存或触发冲突，建议默认禁用，只在需要时手动启用：
-
GitLens：默认开启行级 blame 和历史图谱，gitlens.codeLens.enabled和gitlens.hovers.enabled建议关掉 -
ESLint：若项目没配.eslintrc.js或eslint.probe未限定路径，会扫整个node_modules，内存轻松破 800MB -
ms-python.python（含 Pylance）：启动后常驻 1.2GB+，可在该工作区设python.languageServer为Jedi或直接禁用 - AI 类插件（如
aliyun.aliyun-lingma）：后台构建本地索引，不同工作区索引互不共享，重复加载极易爆内存
验证是否真隔离：
- 运行
code --status记下 Extension Host PID - 执行
ps -p [pid] -o args=（macOS/Linux）或查任务管理器“详细信息”页命令行 - 输出里还出现
gitlens、pyright、tsserver等关键词 → 没成功
Dev Containers 是终极隔离，但代价明确
当项目依赖版本冲突严重（比如 Node.js 16 vs 20、Python 3.8 vs 3.12）、或需要完全干净的扩展环境时，Dev Containers 是唯一能彻底隔离插件运行时的方案。
但它不是“一键开关”，而是完整环境重建：
- 每次打开都需拉镜像、装依赖、重装插件（即使已装过）
- 启动慢，尤其首次或镜像更新后
-
.devcontainer/devcontainer.json中声明的插件，只在容器内生效，宿主机插件完全不可见
Profile 和 Dev Containers 的核心区别在于：Profile 隔离的是“用户态配置”，Dev Containers 隔离的是“整个运行时沙盒”。前者快但仍有共享层，后者重但真干净——选哪个，取决于你愿为确定性付出多少等待时间。
