靠 .vscode/extensions.json 和 .vscode/settings.json 提交到 git 实现团队配置统一，而非 settings sync；因 sync 会全量合并扩展、无法区分必需/可选、不提示缺失、易推入冲突插件，且在内网或 sso 环境常失效，也无版本约束与上下文引导。
直接结论：靠 .vscode/extensions.json + .vscode/settings.json 提交到 Git，不是靠同步账号或手动安装。
为什么不能只靠 Settings Sync 同步扩展
Settings Sync 会把所有设备上的扩展全量合并，但团队项目只需要特定几个——比如 Python 项目不该强制同步 Rust 插件；更关键的是，它无法区分“必需”和“可选”，也不提示缺失插件。一旦某人本地装了冲突扩展（如两个 Formatter），Sync 还会把它推给所有人。
- 企业内网或 GitHub SSO 环境下，Settings Sync 经常被禁用或登录失败
- 同步的扩展列表不带版本约束，
ms-python.python更新到 v2026.1 后可能破坏旧项目调试逻辑 - 没有上下文：新人 clone 仓库后，根本不知道该装哪些扩展，除非点开“推荐”标签页并主动操作
extensions.json 的正确写法与常见错误
这个文件只起“推荐”作用，VSCode 会在打开工作区时自动弹出提示，但不会强制安装。它的价值在于把扩展选择从口头约定变成可审查、可 diff 的代码。
- 必须放在项目根目录的
.vscode/extensions.json路径下，否则 VSCode 不识别 - 字段名是
recommendations，不是extensions或required—— 写错就完全失效 - 扩展 ID 必须准确，例如 Prettier 是
esbenp.prettier-vscode，不是prettier或prettier-vscode - 可加
unwantedRecommendations屏蔽已知冲突插件，比如禁用ms-vscode.js-debug-nightly避免覆盖稳定版调试器
示例：
{
"recommendations": [
"esbenp.prettier-vscode",
"dbaeumer.vscode-eslint",
"ms-python.python"
],
"unwantedRecommendations": ["ms-vscode.js-debug-nightly"]
}
settings.json 怎么配合扩展生效
光推荐插件没用，必须在 .vscode/settings.json 中绑定行为。VSCode 工作区设置优先级高于用户设置，所以能覆盖个人习惯。
-
"editor.defaultFormatter"必须设为推荐的 Formatter 扩展 ID，否则formatOnSave会 fallback 到内置逻辑，格式不一致 - Python 项目要配
"python.defaultInterpreter"，但别写死绝对路径——用./venv/bin/python（macOS/Linux）或./venv/Scripts/python.exe（Windows），再用 OS-specific override 区分 - ESLint 相关设置如
"eslint.validate"必须显式声明语言数组，否则只校验 JS，漏掉 TSX 或 Vue 单文件 - 避免在 settings.json 里写敏感值，比如 API key 或 token；这类配置应走
.env+ 扩展（如 DotENV）读取
容易被忽略的协作盲区
很多人提交了 .vscode 目录就以为万事大吉，但真正卡住新人的往往是三件事：
-
.editorconfig没配：它比settings.json更底层，能跨编辑器统一缩进、换行符，VSCode 默认支持，但团队常忘了提交 - 没说明“首次打开后要点 Install All”：VSCode 只在 Extensions 视图的 “Recommended” 标签页显示插件，不弹窗强提示，新人容易跳过
- 没验证 Dev Container 是否真能拉起：如果
.devcontainer/devcontainer.json里引用的镜像已下线，或features依赖网络，新成员会卡在 “Reopen in Container” 步骤，且错误信息藏在 Remote-Containers 日志里，极难定位
