禁用插件不等于进程退出，因VSCode插件激活后常驻Extension Host内存，仅Disable (Workspace)有效，但需彻底关闭并重开窗口验证；Profile才是真隔离方案，Dev Containers适用于极端环境。
为什么禁用插件不等于插件真退出
你点了 Disable (Workspace)，界面显示“已禁用”，但内存没降——这不是 UI 欺骗你，而是 VSCode 插件机制本身的设计缺陷：插件一旦激活，其进程（Extension Host）就常驻内存，除非彻底重启窗口。全局禁用、重载窗口（Developer: Reload Window）都无效，旧进程仍在后台跑着 gitlens、pyright 或 tsserver。
- 必须用
Disable (Workspace)，不是Disable (Global) - 禁用后要完全关闭当前窗口（macOS 还得退出菜单栏图标），再用
code .重新打开该工作区 - 验证是否成功：运行
code --status记下 Extension Host PID，再执行ps -p [pid] -o args=，输出里不应出现目标插件名
Profile 是唯一真正隔离插件的方案
VSCode 1.84+ 内置的 Profile 功能，才是解决“不同项目用不同插件”的正解。它不是推荐、不是覆盖，而是为每个 Profile 维护一套独立的已安装扩展列表、设置、快捷键和代码片段——相当于开了多个互不通信的 VSCode 实例。
- 创建方式：命令面板输入
Profile: Create Profile，命名如frontend-react或backend-python - 绑定项目：打开目标文件夹 → 左下角点击 Profile 名 →
Apply Profile to Folder - 切换时自动生效：下次用 Finder / Explorer 打开该文件夹，VSCode 会直接加载对应 Profile，无需手动选择
- 注意：Profile 不会自动同步扩展安装状态，首次应用需手动启用所需插件（如
ms-python.python或esbenp.prettier-vscode）
.vscode/extensions.json 只能推荐，不能强制隔离
.vscode/extensions.json 的作用是提示团队成员“该装哪些插件”，但它对已安装插件无任何禁用或卸载能力。如果你本地已装了 50 个插件，打开一个只推荐 3 个的项目，那 47 个仍会按规则尝试激活——尤其是 GitLens、ESLint 这类监听文件系统事件的插件，一打开项目就拉起进程。
- 适合场景：协作项目中统一开发环境引导，比如新成员克隆仓库后看到推荐列表一键安装
- 不适合场景：防止内存暴涨、避免插件冲突（如
Vetur和Vue - Official同时处理.vue文件） - 若想弱化干扰，可在
.vscode/settings.json中关掉相关功能开关，例如："gitlens.codeLens.enabled": false、"eslint.enable": false
Dev Containers 是终极隔离，但代价是启动慢
当项目依赖版本冲突严重（比如 Node.js 16 vs 20、Python 3.8 vs 3.12）、或需要完全干净的扩展环境时，Dev Containers 是唯一能绕过宿主机插件污染的方案。它把整个 VSCode 前端 + 扩展 + 运行时全塞进 Docker 容器里运行。
- 配置核心是
.devcontainer/devcontainer.json，其中customizations.vscode.extensions列出容器内专属插件 ID - 宿主机上装的插件对容器内完全不可见，反之亦然
- 代价明显：每次打开需构建/拉镜像，首次启动可能耗时 30 秒以上；调试、文件监听延迟略高；无法直接访问宿主机 GUI 工具（如 Chrome DevTools）
- 适合：微服务多语言栈、遗留系统维护、CI/CD 环境复现
Profile 能解决 90% 的插件隔离需求，但很多人卡在“创建完没绑定文件夹”或“以为禁用就完事”。真正的隔离不是配置完就结束，而是每次打开项目时，你得确认左下角 Profile 名字对不对、code --status 里没残留进程、终端里 ps 输出干净——漏掉任意一环，插件就在后台悄悄吃内存。
