vscode插件启用状态以工作区级配置优先，但需注意.code-workspace中插件配置不被子文件夹继承，且.vscode/extensions.json的隐式启用行为优先级最高，会覆盖所有enabled设置。
插件启用状态在工作区和用户级配置中打架
VSCode 会按顺序合并 settings.json：用户级 → 工作区级 → 文件夹级（多根工作区下）。当同一插件在不同层级被设为 "extensionId.enabled": true 和 false，工作区设置优先，但部分插件（如 esbenp.prettier-vscode）的启用逻辑还受 extensions.autoUpdate 或 extensions.ignoreRecommendations 影响，导致看似“已禁用”却仍在格式化。
实操建议：
- 打开工作区
.vscode/settings.json，搜索"extensions."相关字段，删掉冗余的启用/禁用项；只保留明确意图的配置，比如"extensions.ignoreRecommendations": true是全局行为，不应放在工作区 - 检查是否误用了
"extensions.autoCheckUpdates"—— 它控制的是更新检查，不控制启用状态，和enabled无关，混用容易误导判断 - 运行命令
Developer: Show Running Extensions（Ctrl+Shift+P），看目标插件实际运行状态；若显示 “Disabled (Workspace)”，说明工作区settings.json里有"extensionId.enabled": false，且没被其他层覆盖
多根工作区中某文件夹插件配置被意外继承
多根工作区（multi-root workspace）下，VSCode 默认把 `.code-workspace` 文件里的 "settings" 视为顶层配置，而各文件夹下的 .vscode/settings.json 是独立作用域。但如果你在 `.code-workspace` 中写了 "emeraldwalk.runonsave": {...}，又在子文件夹里也配了同名插件，后者不会自动覆盖前者——而是被忽略，除非你在子文件夹设置里显式加 "override": true 语义（但 VSCode 不支持该关键字）。
实操建议：
- 避免在 `.code-workspace` 中配置具体插件行为（如保存时执行命令），这类配置应下沉到对应文件夹的
.vscode/settings.json中 - 若必须差异化控制，用
"[javascript]": { "editor.formatOnSave": true }这类语言关联配置替代全局插件开关，更稳定 - 检查
Extensions: Show Enabled Extensions命令输出，确认插件是否真正在当前文件夹上下文中激活；注意右下角语言模式状态栏，它直接影响[lang]配置块是否生效
插件推荐弹窗关闭后仍反复触发冲突
VSCode 的推荐机制（extensions.showRecommendationsOnlyOnDemand）默认关闭，只要工作区含 package.json 或 tsconfig.json，就会主动推荐相关插件，并可能自动写入 extensions.ignoreRecommendations 到工作区设置——这会抑制你手动启用的插件，尤其是团队共享工作区时。
实操建议：
- 在工作区
.vscode/settings.json中显式设置"extensions.ignoreRecommendations": false，防止被隐式覆盖（注意：设为false才是“不禁用推荐”，不是留空或删掉该行） - 如果团队统一禁用推荐，应在用户级
settings.json设置，而非提交到仓库；或改用.vscode/extensions.json的"recommendations"字段做声明式管理 - 删除
.vscode/extensions.json后重启 VSCode，观察推荐是否重现——该文件存在时，VSCode 会强制启用列表中插件，无视enabled设置
最易被忽略的是 .vscode/extensions.json 的隐式启用行为，它比任何 settings.json 中的 enabled 字段都强势；另外，插件自身是否支持工作区级配置（比如 prettier 支持 prettier.configPath，但 gitlens 的某些功能仅响应用户级设置），得查插件文档里 “Workspace support” 标注，不能默认所有字段都可工作区覆盖。
