VSCode插件配置文件：别让extensions.json成了摆设
团队协作开发时，如何确保每位成员都安装了必要的VSCode插件？答案就在项目根目录下的.vscode/extensions.json文件里。但现实往往是，你精心配置了推荐列表，队友打开项目时却什么提示都没看到。问题出在哪？今天就来拆解这个看似简单、实则暗藏玄机的配置文件。
extensions.json 文件在哪，怎么确认它生效了
首先，文件位置是硬性规定，没有商量余地：它必须放在项目根目录下的.vscode/extensions.json路径。少一个点、多一层目录，或者拼错文件名（比如写成extension.json），都会让VSCode完全忽略它。
那么，怎么判断它是否真的生效了呢？生效与否，不靠“有没有文件”，而是要看VSCode扩展视图底部是否出现了「Workspace Recommendations」区域。如果没看到这个区域，别急着怀疑人生，先按顺序检查下面几点：
.vscode是一个隐藏文件夹，确保它没有被系统或Git忽略（检查一下.gitignore文件里是不是误写了.vscode）。- JSON格式必须合法：可以用VSCode自带的JSON验证功能（保存时如果有语法错误会报错），或者干脆把内容粘贴到jsonlint.com这类在线工具里检查一遍。
- 确认VSCode设置中没有禁用推荐功能：
extensions.ignoreRecommendations这个设置项必须为false（默认就是false，除非你或者团队之前手动关闭过）。
打开项目后看不到推荐横幅？先查这三处
很多人的困惑在于：文件明明配置对了，为什么打开项目时没有弹出那个熟悉的推荐横幅？这里有个关键认知：不是所有打开方式都会触发提示。只有「首次打开该工作区」或者「手动刷新推荐列表」时，VSCode才会在右下角弹出横幅。
常见的遗漏点通常在这几个地方：
- 你之前已经打开过这个项目（哪怕只是浏览了一下），VSCode就不再视为“首次”——这种情况下，可以去命令面板（
Ctrl+Shift+P）执行Extensions: Show Recommended Extensions for this Workspace来手动调出列表。 - 当前的打开方式是「添加文件夹到已有工作区」，而不是单独打开该文件夹——工作区推荐只对顶层的独立工作区生效。
- 插件ID写错了。这是最高频的错误，比如把
ms-python.python写成ms-python.Python（ID是大小写敏感的），或者漏掉了publisher部分（只写python是不行的，必须是完整的ID）。
怎么快速验证 extensions.json 里的插件 ID 对不对
别凭记忆或者对着截图抄ID，最稳妥的方式是直接从VSCode里获取：
- 在扩展视图（
Ctrl+Shift+X）搜索插件名 → 点进已安装的条目 → 右键 → 选择Copy Extension ID。 - 如果插件还没安装，去市场页面搜索，点进详情页 → 看浏览器地址栏末尾：例如
https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode→ 那么ID就是esbenp.prettier-vscode。 - 复制完之后，立刻粘贴进
extensions.json文件并保存——VSCode会实时校验JSON语法，如果有错误会立刻高亮标红。
unwantedRecommendations 字段容易被当成摆设
这个字段可不是可有可无的装饰。当项目依赖特定版本的TypeScript，或者需要禁用某个调试器时，它能有效防止VSCode自动推荐冲突的插件。来看一个典型例子：
{
"recommendations": ["ms-vscode.vscode-typescript-next"],
"unwantedRecommendations": ["ms-vscode.vscode-typescript"]
}
但使用时必须注意几个细节：
unwantedRecommendations只负责屏蔽推荐，它不会卸载已经安装好的插件。- 它的作用范围仅限于当前工作区，不会影响到你打开的其他项目。
- 如果你发现某个本该被屏蔽的插件仍然出现在推荐区，大概率是ID拼写不一致，比如
ms-vscode.js-debug和ms-vscode.js-debug-nightly，在VSCode看来这是两个完全不同的插件ID。
说到底，真正起作用的永远是那个精确匹配的字符串，而不是模糊的关键词。配置时多花十秒钟核对，能省下后续一大堆沟通成本。
