.vscode/extensions.json是唯一可靠方式，需置于项目根目录的.vscode/下，含"recommendations"字段及准确publisher.name格式插件ID，首次打开工作区时触发「Recommended Extensions」横幅提示。
团队协作出问题，八成不是人的问题，是插件没管好。 VSCode 本身不强制统一环境，靠人自觉装插件、关插件、调配置，迟早踩坑。真正有效的做法，是把插件管理权交还给项目本身——用 .vscode/extensions.json 控制谁该出现、谁该消失。
怎么让新成员一打开项目就知道该装哪些插件
别再发文档截图或口头提醒。VSCode 原生支持工作区级插件推荐，只需在项目根目录建 .vscode/extensions.json：
{
"recommendations": [
"esbenp.prettier-vscode",
"ms-python.python",
"gitlens.gitlens"
]
}
这个文件生效后，新成员首次打开项目，VSCode 就会在 Extensions 面板顶部弹出「Recommended Extensions」横幅，点击一键安装。它不强制安装，但提示明确、路径直接。
-
recommendations列表里的插件，只影响提示行为，不会自动启用或禁用已有插件 - 如果成员本地已装过某个推荐插件，VSCode 不会重复提示，也不会覆盖其设置
- 推荐名必须用完整 ID（比如
gitlens.gitlens，不是gitlens），否则识别失败
怎么阻止某人乱装 Spell Checker 导致提交满屏红色波浪线
拼写检查类插件（如 streetsidesoftware.code-spell-checker）在团队项目里极易引发格式污染：有人开、有人关，有人用美式、有人用英式，结果 PR 里全是无关的 spelling diff。
与其靠口头约定，不如用 unwantedRecommendations 显式屏蔽：
{
"recommendations": ["esbenp.prettier-vscode"],
"unwantedRecommendations": ["streetsidesoftware.code-spell-checker"]
}
这个字段的作用是：一旦检测到该插件已安装，VSCode 会自动禁用其功能（不是卸载），且不再显示相关提示或装饰。
- 它只对已安装的插件起效；没装的插件，不会被阻止安装
- 禁用是工作区级的，不影响该插件在其他项目中的使用
- 注意拼写——ID 错一个字符，就等于没写
为什么不能只靠 settings.json 统一格式化却不管插件本身
很多人以为只要在 .vscode/settings.json 里配好 "editor.defaultFormatter": "esbenp.prettier-vscode" 就万事大吉。但现实是：
- 如果成员没装 Prettier 插件，
defaultFormatter设置无效，保存时根本不会格式化 - 如果成员装了 Beautify 或其他格式化器，而没禁用，它可能抢在 Prettier 前触发，导致双格式化冲突
- ESLint 插件如果没装，
eslint.enable设置就只是个摆设，语法错误照常漏掉
换句话说：settings.json 管行为，extensions.json 管能力。两者必须配套，缺一不可。
Live Share 和 GitLens 这类协作插件要不要推荐
要，但得分类处理：
- 像
ms-vsliveshare.vsliveshare这种实时协作插件，适合放进recommendations—— 它不改变代码，只影响开发过程，且需双方都装才生效 - 像
gitlens.gitlens这种增强 Git 体验的插件，也建议推荐 —— 它能统一查看 blame、提交图、分支对比，减少因工具差异导致的沟通成本 - 但不要把调试器（如
ms-python.python）和语言支持插件混进同一个推荐列表；它们属于基础能力，应单独归类并确保版本兼容性
真正容易被忽略的是：插件推荐不是“越多越好”，而是“刚好够用”。一个项目里塞二十个推荐插件，反而会让新成员放弃阅读——重点永远是那三四个决定代码质量和协作效率的核心插件。
