全局装插件在大型项目里等于自找麻烦，因其导致VSCode启动时多个扩展争抢资源、CPU飙升、响应延迟；应改用工作区级白名单配置extensions.enabled和多根独立.settings.json实现精准控制。
为什么全局装插件在大型项目里等于自找麻烦
VSCode 启动时默认扫描所有已安装扩展，而每个扩展都可能注册自己的激活事件（如 onLanguage:typescript、workspaceContains:tsconfig.json）。在含十几个子包、多个语言栈的 monorepo 里，一旦你全局装了 Python、Rust、Tailwind、GitLens、Auto Import —— 它们会在你打开 frontend/ 的瞬间集体尝试加载，争抢文件监视器和 CPU 资源。这不是“多装几个插件”，是让编辑器同时运行七八个独立 Node.js 子进程。
常见错误现象：Code Helper (Renderer) 进程 CPU 占用长期超 80%；打开一个 .tsx 文件后 3 秒内无响应；右键菜单延迟半秒才弹出。
- 别信“我只装了 5 个插件”——检查
~/.vscode/extensions/目录，你会发现很多是被其他插件悄悄带进来的依赖 - 禁用某个插件 ≠ 停止它的后台活动：有些插件（如 GitLens）即使界面功能关了，仍持续拉取 Git 历史
- 远程开发（SSH / Containers）下，扩展行为更不可控：本地装的插件不会自动同步到远端，但远端装的又可能不兼容你的本地配置
工作区级禁用必须靠 settings.json，不是右键点一下就完事
命令面板里搜 Disable Extension in Workspace 确实方便，但它生成的配置是 "extensions.disabled": ["xxx"]，而这个字段在 VSCode 1.89+ 已被标记为 deprecated。真正起效且受支持的是 "extensions.enabled" 白名单模式。
正确写法示例（放在项目根目录 .vscode/settings.json 中）：
{
"extensions.enabled": [
"esbenp.prettier-vscode",
"ms-vscode.vscode-typescript-next",
"bierner.emojisense"
]
}
这意味着：只有这三项会被加载，其余全部无视。比 disabled 更干净、更可预测。
-
extensions.enabled是白名单，extensions.disabled是黑名单 —— 大型项目推荐前者，避免漏掉新装插件 - 该配置只对当前工作区生效，不影响其他项目，也不影响用户级设置
- 如果某插件没出现在列表里，它连
activate()函数都不会执行，彻底零开销
多根工作区下，每个子目录都要有自己的 .vscode/settings.json
把 apps/web、packages/api、shared/utils 全加进一个 .code-workspace，不代表它们能共享配置。VSCode 的语言服务（TS Server、ESLint、Prettier）都是按“当前打开文件路径”就近查找配置的，不会跨根合并。
典型问题：apps/web/src/App.tsx 里写了 import { log } from 'shared'，跳转失败或报 Cannot find module 'shared' —— 不是因为路径映射没配，而是 shared/ 根目录下没启用 TypeScript 插件，或者 apps/web 根目录下没启用 ESLint 的 import/resolver。
- 每个子目录必须有独立的
.vscode/settings.json，哪怕内容只有{"typescript.preferences.importModuleSpecifier":"relative"} - 不要在
.code-workspace文件里写extensions字段 —— 它只对第一个根生效，其余全忽略 - 若子包使用不同语言（如 backend/ 是 Python），就在其
.vscode/settings.json里明确关掉 TS/JS 相关插件："typescript.languageServer":"off"
extensions.json 是团队协同的隐性契约，不是可有可无的提示
很多人把 .vscode/extensions.json 当成“建议装啥”，其实它是团队强制对齐工具链的最小单元。VSCode 会读取这个文件，在成员首次打开项目时弹出统一安装提示；更重要的是，它还能主动屏蔽干扰项。
标准模板（放在项目根目录）：
{
"recommendations": ["esbenp.prettier-vscode", "dbaeumer.vscode-eslint"],
"unwantedRecommendations": ["bracket-pair-colorizer.bracket-pair-colorizer", "formulahendry.auto-rename-tag"]
}
unwantedRecommendations 是关键：它不只是“不推荐”，而是直接从扩展市场搜索结果中隐藏这些插件，防止新人手滑装错。
- 团队仓库必须把
.vscode/extensions.json提交进 Git —— 这是环境一致性最轻量的保障 - 别用
extensions.ignoreRecommendations: true一刀切，它会同时屏蔽真正需要的推荐 - 某些插件（如 Volar）要求特定 VS Code 版本，可在
extensions.json里配合engines.vscode做版本约束
真正难的不是“怎么禁用”，而是判断哪个插件该在哪个层级禁用。比如 GitLens 在 frontend/ 里要看 blame，在 backend/ 的 Python 目录里却纯属累赘；这种细粒度控制没法靠开关解决，得靠每个子目录的 settings.json 显式声明行为边界 —— 配置即文档，边界即稳定。
