必须禁用extensions.autoUpdate，否则插件可能静默升级导致API变更、配置解析失败或Node版本不兼容，破坏CI构建一致性；需配合extensions.json推荐版本、Dev Container固定安装及人工核对更新日志。
必须禁用自动更新，否则构建脚本可能在CI中突然失效——这不是概率问题，而是已知的版本漂移风险。
为什么禁用 autoUpdate 是硬性前提
VSCode 插件更新不走语义化版本约束，extensions.autoUpdate 一旦开启，插件可能在你不知情时从 1.2.3 升到 2.0.0，而新版可能：删掉旧 API（如 vscode.workspace.findFiles 返回类型变更）、改写配置解析逻辑（如 ESLint 插件跳过 .eslintrc.cjs）、或强制要求新 Node.js 版本（导致 CI 中 npm install 失败）。这类变更不会触发 package-lock.json 更新，但会静默破坏本地构建一致性。
- 禁用后，所有扩展停留在你验证过的版本，CI 流水线才能复现本地行为
- 团队成员不再因“别人能跑通、我报错”反复排查环境差异
- 你主动升级时，可结合
code --list-extensions --show-versions输出做版本比对
如何锁定关键插件的具体版本
VSCode 原生不支持 extensions.versionPin 这类配置，但可通过以下组合实现事实锁定：
- 在项目根目录创建
.vscode/extensions.json，内容为：{ "recommendations": [ "ms-python.python@2023.10.1", "esbenp.prettier-vscode@9.13.0", "vue.volar@1.12.1" ] }——这仅起提示作用，不阻止更新 - 真正生效的是配合
extensions.autoUpdate: false+ 团队文档明确列出“经验证可用版本”，例如：ms-vscode.vscode-typescript-next@5.4.20240410（注意含日期的预发布版更稳定） - 若用 Dev Container，直接在
.devcontainer/devcontainer.json的customizations.vscode.extensions数组里写死带版本号的 ID，容器重建时会强制安装指定版本
哪些插件更新最危险，需要重点盯防
不是所有插件都同等危险。以下三类更新后极易引发构建失败：
-
ESLint/Prettier类：规则引擎变动会直接让npm run lint报新错误，甚至因解析器不兼容卡住 Webpack 构建流程 -
CMake Tools：新版可能改写tasks.json生成逻辑，导致cmake --build调用路径错误，报command not found -
Java Extension Pack：更新后可能重写launch.json中的vmArgs，使 JVM 参数格式失效，java -jar启动失败
这些插件的更新日志必须人工逐条核对，尤其留意 “Breaking Changes” 和 “Configuration changes” 小节——它们不会出现在 VSCode 的简略更新弹窗里。
CI 环境中还要额外做的一件事
CI runner（如 GitHub Actions 的 ubuntu-latest）默认不装 VSCode，但如果你用 vscode-test 或 extension-tester 做插件 E2E 测试，必须显式指定 VSCode 版本，并确保插件版本与之匹配：
- 用
vscodeVersion: '1.107'时，ms-python.python必须用@2023.10.1（适配 TS 5.4 的版本），而非最新版 - 避免在 CI 脚本里执行
code --install-extension ms-python.python，应改为code --install-extension ms-python.python@2023.10.1 - 本地
settings.json中的typescript.tsdk路径若指向全局 TS，CI 中需同步设为"typescript.tsdk": "./node_modules/typescript/lib"，否则类型检查结果不一致
真正的难点不在“怎么锁版本”，而在于识别哪些插件的哪些变更会穿透到构建层——比如 Volar 更新可能不影响编辑体验，但会让 vite build 因 SFC 类型推导错误而中断，这种链路容易被忽略。
