多根工作区中插件被静默禁用的根源是 vscode 按策略优先解析 .vscode/extensions.json 中的 "unwanteddependencies" 等配置，覆盖用户级设置，甚至绕过 extensions.disabledextensions；远程开发时 devcontainer.json 的扩展配置优先级更高；验证方法包括命令行绕过工作区启动或重命名 .vscode 目录；还需排查 json 语法错误、id 拼写错误及语言服务器进程残留。
多根工作区中插件被静默禁用的根源
多根工作区（Multi-root Workspace）下插件“突然不生效”，往往不是插件坏了，而是 VSCode 主动按策略压制了某些扩展——尤其当 .vscode/extensions.json 存在且配置了 "recommendations" 或 "unwantedDependencies" 时。它会覆盖用户级设置，连 extensions.disabledExtensions 都可能被绕过。
常见现象包括：全局启用的 Pylance 在某个工作区里完全不提供悬停提示；通义灵码在 A 工作区正常，在 B 工作区补全图标消失；甚至插件面板里显示“已启用”，但输出日志里压根没加载记录。
-
.vscode/extensions.json中若写了"unwantedDependencies": ["ms-python.python"]，该插件会被强制禁用，无论用户设置如何 - 多个根目录下各自有
.vscode/extensions.json，VSCode 会合并处理，冲突项以最后解析的为准（顺序不可控） - 远程开发（Dev Container）场景下，
devcontainer.json的"customizations.vscode.extensions"优先级高于本地工作区配置，可能直接屏蔽掉你依赖的本地插件
如何快速验证是否是工作区配置导致的异常
别进设置翻来翻去，直接用命令行启动并绕过所有工作区级干预：
- 关闭当前窗口，终端执行：
code --disable-extensions --no-sandbox --disable-gpu，再手动打开单个文件夹（非工作区），看插件是否恢复 —— 若恢复，说明问题出在工作区配置或其加载逻辑 - 临时重命名当前工作区的
.vscode目录（如改为.vscode.bak），然后重新打开工作区。如果插件立刻生效，问题 90% 出在.vscode/extensions.json或.vscode/settings.json里 - 检查
settings.json是否含"extensions.ignoreRecommendations": true—— 这个开关会让 VSCode 彻底跳过extensions.json的推荐加载，但不会影响unwantedDependencies
排查 extensions.json 冲突的实操要点
VSCode 对 extensions.json 的解析很机械，小错误会导致整块失效或反向压制。重点查三类内容：
- 语法错误：JSON 格式不合法（如末尾多逗号、引号不闭合）会让整个文件被忽略，此时 VSCode 退回到用户级设置，但你可能误以为“配置没起作用”
-
"unwantedDependencies"列表里写了插件 ID，但拼写错误（比如ms-pyhton.python少了个h），VSCode 不报错，但该插件仍会被当作“已声明禁用”处理 - 多根工作区中，不同根目录下的
extensions.json若对同一插件给出矛盾指令（一个推荐、一个列为 unwanted），VSCode 通常以“禁用”为最终结果，且不提示
建议用 VSCode 自带的 JSON 验证（右键 → Format Document）+ 手动检查 unwantedDependencies 字段是否存在冗余项。
真正麻烦的是语言服务器进程残留
即使你禁用了某个插件，它的语言服务器（如 gopls、pylance、tailwindcss-intellisense）可能已在后台运行，并持续监听文件变更。多根工作区切换时，旧进程未退出，新工作区又尝试拉起同名服务，导致端口占用、响应延迟或静默挂起。
- 打开任务管理器（Ctrl+Shift+Esc），筛选进程名含
exthost或code helper，观察 CPU / 内存占用突增后是否回落 —— 若不回落，大概率是某语言服务器卡死 - 运行命令
Developer: Show Running Extensions，重点关注Status列为Activation failed或Activation Time超过 2000ms 的插件 - 最干净的做法：关掉所有 VSCode 窗口 → 终端执行
pkill -f "gopls\|pylance\|tailwindcss"（Linux/macOS）或任务管理器结束对应进程（Windows）→ 再重新打开工作区
这类问题不会在 UI 报错，也不会写进常规日志，只有在 Developer: Open Extension Host Log 末尾看到超长等待或 connection refused 才能确认。别等崩溃，先清进程。
