.vscode/extensions.json是VSCode唯一官方支持的团队插件推荐机制，须置于项目根目录下.vscode/中，字段名必须为recommendations，值为准确插件ID（如esbenp.prettier-vscode）组成的数组，并可选unwantedRecommendations屏蔽冲突项。
怎么用 .vscode/extensions.json 精准推荐团队必需扩展
靠 Settings Sync 同步插件会把所有人装过的扩展全堆进来，Python 项目里混进 Rust 插件、两个 Formatter 冲突、新人 clone 后根本不知道该装啥——这些都不是配置问题，是推荐机制没用对。
extensions.json 的作用不是强制安装，而是把“这个项目该用哪些扩展”变成可审查、可 diff 的声明。它只在项目根目录的 .vscode/extensions.json 路径下生效，字段名必须是 recommendations，写成 extensions 或 required 就完全不触发。
- 扩展 ID 必须完整准确，比如 Prettier 是
esbenp.prettier-vscode，不是prettier或prettier-vscode - 用
unwantedRecommendations主动屏蔽已知冲突项，例如禁用ms-vscode.js-debug-nightly避免覆盖稳定版调试器 - 推荐列表不带版本约束，
ms-python.python升级到 v2026.1 后可能破坏旧项目调试逻辑，需配合settings.json中的解释器路径做兼容控制
为什么 .vscode/settings.json 必须和扩展联动才真正生效
光推荐 Prettier 没用，editor.defaultFormatter 不设成 esbenp.pretterr-vscode，保存时照样 fallback 到 VSCode 内置格式逻辑；光推荐 ESLint，但没配 eslint.enable: true 和 eslint.packageManager，错误提示就压根不出。
工作区设置优先级高于用户设置，所以能覆盖个人习惯，但这也意味着：如果本地 settings.json 里写了 "files.insertFinalNewline": true，而 .editorconfig 里是 insert_final_newline = false，VSCode 会以 settings.json 为准——EditorConfig 插件不会强行覆盖它。
- Python 项目要设
python.defaultInterpreter，但别写死C:\Users\...这种绝对路径，改用./venv/Scripts/python.exe（Windows）或./venv/bin/python（macOS/Linux） - 用
"[python]": { "editor.formatOnSave": true }这类语言专属块，避免全局污染其他语言行为 - 远程开发（Remote-SSH / Dev Containers）下，
settings.json必须放在容器内或远程工作区路径下才生效，本地同名文件无效
EditorConfig 和 Linter/Formatter 怎么不打架
很多人以为装了 EditorConfig 插件、写了 .editorconfig，缩进和换行就自动统一了。实际常出现“保存后还是 4 空格”，原因往往是 ESLint 或 Prettier 的规则跟 .editorconfig 冲突，或者插件根本没激活。
EditorConfig 只管基础编辑行为（缩进大小、是否 trim 尾空格、换行符），不管代码语义。而 ESLint、Prettier、Black 这些是语义级格式器，它们读取的是项目里的 .eslintrc、.prettierrc、pyproject.toml ——这些文件才是团队规则的真实源头。
- 验证 EditorConfig 是否生效：打开一个
.js文件，看右下角状态栏是否显示缩进数值，且随.editorconfig修改实时变化 - 确保
settings.json中关闭冲突项，比如禁用"editor.detectIndentation": false，否则 VSCode 会根据文件首行自动猜缩进，覆盖.editorconfig - Prettier 默认忽略
.editorconfig，必须在.prettierrc里显式写"useTabs": false, "tabWidth": 2才能对齐
Live Share 和 Dev Containers 怎么共存不翻车
Live Share 共享的是当前工作区上下文（光标、断点、终端），但它不共享扩展、不共享 .vscode 配置，也不部署 Dev Container。换句话说：你开 Live Share 会话，对方看到的是你本地环境跑起来的代码，而不是容器里的。
想让协作成员都运行在一致环境里，得用 Dev Containers + Remote-SSH 组合：先通过 .devcontainer.json 定义镜像、扩展、端口映射，再让所有人连到同一台远程机器或各自拉起相同容器。Live Share 可以在这个基础上叠加，共享调试会话和终端输出。
- Dev Container 的
extensions.json要放.devcontainer/目录下，不是项目根目录的.vscode/，否则远程容器里不读 - Live Share 不支持转发容器内部端口，如果服务跑在
localhost:3000容器里，得用"forwardPorts": [3000]显式暴露，再在 Live Share 里手动共享该端口 - 多人同时 attach 同一调试进程时，
Session Broker会按权限分发断点，但变量查看依赖 Debug Adapter 实现，Python 用debugpy、Node.js 用js-debug，选错适配器会导致“能看到断点，看不到变量值”
团队协作工具套件真正落地的复杂点不在安装，而在“谁在什么时机、以什么方式加载哪一层配置”。.vscode/extensions.json 和 .devcontainer.json 看似相似，但加载时机、作用域、生效范围完全不同；settings.json 里一行配置，可能被远程环境、语言专属块、甚至 EditorConfig 插件悄悄覆盖。这些细节不抠清楚，协作环境就永远停留在“看起来差不多”的阶段。
