VSCode 不支持仅对非活动窗口禁用插件，因其所有窗口共享同一个 Extension Host 进程，插件激活后全局驻留；唯一可靠隔离方式是使用 Profile（1.84+），或诊断时用 code --disable-extensions。
VSCode 本身不支持“仅对非活动窗口禁用插件”——这是个根本不存在的功能。多窗口之间共享 Extension Host 进程，插件一旦激活就全局驻留，无法按窗口粒度开关。
为什么“禁用非活动窗口插件”在 VSCode 中不可行
VSCode 的插件运行机制决定了它没有“窗口级激活”概念：所有窗口共用同一个 Extension Host 进程；只要某个插件响应了 activationEvent（比如打开一个 .py 文件触发了 Python 扩展），它就会常驻内存，服务所有窗口。你关掉一个窗口、切到另一个窗口，插件照样在后台跑着——code --status 查到的 PID 是同一个，ps -p [pid] -o args= 里照样能看到 gitlens 或 pyright 的路径。
常见误解来源：
- 误把“工作区禁用”当成“窗口禁用”：禁用只写配置，不清理进程
- 看到多个 VSCode 窗口图标，以为是独立进程——其实只是 GUI 实例，Extension Host 是单例
- 观察到某窗口没触发格式化，就以为插件“没加载”，实际是事件未触发或配置未命中
真正能隔离插件的唯一可靠方式：Profile
VSCode 1.84+ 引入的 Profile 是目前唯一能实现“不同窗口/项目间插件完全不共享”的方案。它不是视觉分组，而是逻辑隔离：每个 Profile 拥有独立的已启用扩展列表、设置、快捷键、代码片段，互不干扰。
实操步骤：
- 命令面板输入
Profile: Create Profile，命名如frontend或backend - 打开目标项目文件夹 → 左下角点击 Profile 名 →
Apply Profile to Folder - 该文件夹下次双击打开时，VSCode 自动加载对应 Profile，且只启用你手动勾选的插件
注意：Profile 不同步已安装状态。首次应用后，需在该 Profile 下重新启用所需插件（例如 esbenp.prettier-vscode），否则即使插件已装，也不会出现在扩展列表中。
禁用插件后仍吃 CPU？先确认是否真被停掉
点完 Disable (Workspace) 或改了 extensions.enabled，不代表插件立刻退出。必须执行以下任一操作才能让变更落地：
-
Developer: Reload Window（最常用，但仅重载当前窗口） - 彻底关闭当前窗口（macOS 还要退出菜单栏图标），再用
code .重新打开文件夹（唯一能清空 Extension Host 的方式）
验证是否生效：
- 运行
Developer: Show Running Extensions，看目标插件是否还在列表中，尤其关注Activation Events列含"*"或"onStartupFinished"的项 - 终端执行
code --status记下 Extension Host PID，关窗重开后再比对ps -p [pid] -o args=输出，目标插件名不应出现
想临时排除插件干扰？用 code --disable-extensions
这不是配置，而是启动参数：在终端运行 code --disable-extensions /path/to/project，VSCode 会以零插件状态启动，所有扩展完全不加载，Extension Host 进程里连名字都看不到。适合快速验证是否为插件冲突导致的问题（比如补全失效、保存卡顿）。
优势明显：
- 无需修改任何配置，关掉窗口即恢复原状
- 绕过所有工作区设置、
unwantedDependencies、extensions.disabled的潜在干扰 - 比禁用单个插件更干净，适合排查疑难问题
缺点也很明确：所有插件全关，包括你依赖的主题、语言支持等，仅适合诊断场景，不能作为日常策略。
归根结底，VSCode 的插件模型是进程级而非窗口级。想靠“关掉某个窗口就自动卸载插件”来省资源，这条路走不通。真正有效的隔离，只有 Profile；快速诊断，只用 --disable-extensions；而所有“禁用后还跑”的现象，几乎都源于没彻底重启 Extension Host 进程——这点最容易被忽略。
