插件未加载到多工作区是因为插件本身不绑定工作区，其行为受工作区settings.json和全局设置双重影响：例如eslint.enable设为false时，即使插件已安装启用也不会生效；插件激活取决于activationEvents声明（如onLanguage:javascript），而非工作区结构。
为什么插件没加载到多工作区里
插件本身不绑定工作区，但插件行为受工作区 settings.json 和全局设置双重影响。比如 eslint.enable 在工作区里设为 false，即使插件已安装并启用，也不会对当前文件夹生效。
- 插件是否激活，取决于它声明的
activationEvents（如onLanguage:javascript），而非工作区结构 - 工作区级
.vscode/settings.json可覆盖插件默认行为，例如把prettier.requireConfig设为true后，若项目根目录没有.prettierrc，格式化会静默失效 - 某些插件（如
ms-python.python）依赖python.defaultInterpreterPath，这个路径若写在工作区配置里，只对该工作区生效；若写在用户设置里，则所有工作区共享——但同步时会被 Settings Sync 静默过滤
自定义 --extensions-dir 后工作区还能正常读插件吗
能，但前提是 VSCode 启动时明确传入该参数。工作区本身不记录或感知插件路径，它只通过 VSCode 进程加载的插件实例提供功能。
- 如果你用快捷方式双击打开 VSCode，默认走的是系统注册表/桌面文件里的启动命令，很可能没带
--extensions-dir，导致插件目录“回退”到默认路径 - macOS 上通过 Spotlight 或 Dock 启动的 VSCode 通常不继承终端环境变量，
--extensions-dir必须显式写进Applications/Visual Studio Code.app/Contents/MacOS/Electron的包装脚本，或改用open -a "Visual Studio Code" --args --extensions-dir /path - Windows 下若用
code命令行启动，必须确保 PATH 中的code是你手动安装的 Shell 命令，而不是旧版残留——否则--extensions-dir可能被忽略
settings.json 里哪些字段会破坏插件与路径协同
不是所有配置项都安全。有些字段一旦出现在工作区或用户设置中，会直接干扰插件对路径的解析逻辑，尤其涉及绝对路径、动态变量或平台特有键名。
-
python.defaultInterpreterPath：值为绝对路径时，在另一台机器上大概率失效；更稳妥的是用${workspaceFolder}或${env:HOME}等变量，但注意ms-python.python对${env:PATH}支持有限 -
terminal.integrated.profiles.*：Windows 下的profiles.windows在 macOS/Linux 上会被完全忽略，且 Settings Sync 会跳过这类字段，导致新设备终端配置为空 -
editor.codeActionsOnSave里若引用了未安装插件的 fixer（如"source.fixAll.eslint"），保存时不会报错，但对应动作彻底静默丢失
工作区推荐插件（extensions 字段）和实际安装的关系
.code-workspace 文件里的 extensions 字段只是“建议”，不是强制安装清单。VSCode 不会自动拉取或启用它们。
- 该字段只在首次打开工作区时，以提示形式出现在扩展面板顶部：“推荐用于此工作区的扩展”，用户仍需手动点击安装
- 即使你写了
"ms-python.python"，如果本地--extensions-dir指向一个空目录，或者插件已被禁用，VSCode 也不会主动恢复它 - 团队协作时，靠这个字段同步插件容易漏掉版本约束——比如
esbenp.prettier-vscode新版可能不兼容老版.prettierrc，但工作区配置里无法指定^9.0.0这类语义化版本
python.defaultInterpreterPath 写在工作区里，却忘了它依赖的 Python 解释器本身是否在该路径下存在；又比如你用 --extensions-dir 把插件挪到 SSD，但工作区里某个任务脚本仍硬编码调用 /home/user/.vscode/extensions/...。路径和插件不是配对关系，而是运行时拼合的结果——错一个环节，整个链路就断。 
