VSCode通过extensions.json锁定必需插件、settings.json定义行为规则、.editorconfig统一底层风格，三者协同即可在本地落地企业级开发规范，无需自研扩展或远程服务。
直接用 extensions.json + .vscode/settings.json + .editorconfig 三件套，就能把企业级开发规范落地到每个开发者本地，不需要写扩展、不依赖远程服务、不改动 VSCode 源码。
如何用 extensions.json 锁定团队必需插件
VSCode 的推荐扩展机制是唯一原生支持“项目级插件声明”的方式，extensions.json 就是它的配置入口。它不控制版本，但能强制提示安装，且兼容所有 VSCode 1.70+ 版本。
- 文件必须放在项目根目录的
.vscode/extensions.json下，内容为纯数组：["esbenp.prettier-vscode", "ms-python.python", "redhat.vscode-yaml"] - 标识符必须准确——比如
ms-python.python不能写成python或ms-python，否则提示失效 - 它只触发首次打开时的弹窗，后续新增插件不会自动提醒；若需强制更新，得靠 CI 流水线校验
code --list-extensions输出是否匹配 - 离线环境无法自动拉取，得配合
.vsix预置包使用（见下一条）
怎样批量静默安装 .vsix 扩展（尤其内网场景）
当无法访问 Marketplace 时，code --install-extension 是唯一可靠手段，但必须用完整路径 + .vsix 文件，不能只传 ID。
- 命令格式：
code --install-extension /path/to/prettier-vscode-12.0.0.vsix，路径必须绝对或相对于当前 shell 工作目录 - 批量执行建议写成 shell 脚本，逐行调用，避免用
xargs导致错误中断后难排查 -
.vsix文件需提前从联网机器导出：用npx vsce package --no-yarn --out prettier.vsix --extensionPath ~/.vscode/extensions/esbenp.prettier-vscode-12.0.0 - 注意版本号嵌在路径里，不同插件版本不能混用；企业镜像仓库也得按
ID@version精确索引
settings.json 里哪些配置真正影响智能体行为
.vscode/settings.json 是企业规范落地的核心载体，但它不是万能开关——很多设置只有对应扩展已启用才生效，且部分字段会被用户全局设置覆盖。
- 关键字段示例：
"prettier.requireConfig": true强制走项目级.prettierrc；"editor.formatOnSave": true开启保存即格式化 - 敏感配置如
"security.allowedUntrustedExtensions"或"extensions.autoUpdate"在 Workspace Trust 关闭时无效 - 若启用 Dev Container，
settings.json必须放在.devcontainer.json同级目录，否则容器内不加载 - 不要写
"editor.tabSize": 2这类基础设置——应统一收口到.editorconfig，避免语言间冲突
为什么.editorconfig 比 settings.json 更适合作为风格基准
.editorconfig 是跨编辑器、跨语言的最小公约数，VSCode 原生解析它，且优先级高于 settings.json 中同名设置，适合定义缩进、换行、编码等底层规则。
- 必须命名为
.editorconfig（开头带点），放在项目根目录，子目录会自动继承 - 常见陷阱：
indent_style = space和indent_size = 2要配对写，单独写tab_width不生效 - 对 TypeScript/Go/Python 等语言均有效，但无法控制 Prettier 的括号风格或 quote 类型——那些仍得靠
.prettierrc - Git 提交时若发现
.editorconfig被修改，应视为规范变更，需走 CR 流程，而非个人随意调整
真正难的是让 settings.json 和 .editorconfig 的边界清晰，以及确保 extensions.json 列出的插件确实能在目标 VSCode 版本上稳定工作——特别是涉及 Remote-SSH 或 Dev Containers 时，插件兼容性必须查官方 changelog，不能只看 Marketplace 页面标注的“支持”。
