VSCode插件更新不自动安装或升级依赖项，仅替换自身代码；所有运行时依赖（如LSP服务、Python解释器、Node版本等）必须提前手动满足，否则更新后立即失效。
VSCode 插件更新本身不自动安装或升级其依赖项，所有运行时依赖必须提前满足，否则更新后立即失效。
插件更新时 dependencies 不会自动重装
VSCode 的更新机制只替换插件自身的代码文件（即 .vscode/extensions/publisher-name.extension-name-version/ 目录），完全不触碰 node_modules 或全局命令行工具。这意味着：
- 如果插件依赖
yaml-language-server，而你之前是用npm install -g yaml-language-server装的，更新插件后这个二进制仍需存在且在$PATH中 - 如果插件依赖本地
node_modules里的包（如esbuild），它必须已在插件打包前被npm install进入dependencies字段，并随.vsix一起发布——更新时不会重新运行npm install -
devDependencies在插件运行时根本不可见，更新前后都无效
如何判断一次更新是否需要手动干预依赖
关键不是看“插件有没有更新”，而是看 package.json 里的 dependencies 和 engines 是否变了。更新后功能异常，90% 源于以下三类变更未被察觉：
-
"engines": {"vscode": "^1.85.0"}→ 升级后要求 VSCode 1.85+，旧版直接禁用插件 -
"dependencies": {"typescript": "5.4.5"}→ 改成"5.5.0"，但插件未自带该版本，又没声明为 optional，就会报Cannot find module 'typescript' - Changelog 里出现
Drop support for global eslint→ 表示不再兼容全局安装的eslint，必须改用项目内node_modules/.bin/eslint
验证方式：更新后打开命令面板，执行 Developer: Toggle Developer Tools，切换到 Console 标签页，搜索 ERR 或 require 错误。
extensionDependencies 和跨插件调用的真实限制
当插件 A 声明了 "extensionDependencies": ["ms-python.python"]，VSCode 只做一件事：在 A 启用前检查 B 是否已启用。它不保证 B 的 API 可用、不校验 B 的版本、也不处理 B 本身的依赖缺失。
- 比如
redhat.vscode-yaml依赖yaml-language-server，而ms-python.python也依赖同一个 server —— 两个插件可能各自期望不同版本，但 VSCode 不协调冲突 - 如果 B 插件因 Python 解释器缺失而启动失败，A 插件仍会尝试加载，然后在调用
python.getInterpreter时抛出undefined is not a function - 没有机制能“等待 B 初始化完成再启动 A”，所有跨插件通信都基于事件或服务注册，时序需插件自己处理
依赖检查不能只看 manifest.json
很多插件把真实依赖藏在运行时逻辑里，manifest.json 的 dependencies 字段只是冰山一角。真正要查全，得结合三处：
- 打开插件详情页 →
Contributions标签 → 看activationEvents：比如onLanguage:python暗示需要 Python 插件；workspaceContains:**/tsconfig.json暗示需要 TypeScript 语言服务 - 查插件源码（GitHub 或本地
.vscode/extensions/xxx）中的package.json，重点关注dependencies和optionalDependencies - 终端执行插件实际调用的命令，例如：
which tsc（TypeScript 插件）、rust-analyzer --version（Rust 插件）、dotnet --list-sdks（Q# 插件）
最容易被忽略的是“隐式环境依赖”：某些插件在 Windows 上依赖 PowerShell，macOS 上依赖 gsed 替代 sed，Linux 上依赖 libsecret 库——这些都不会写在任何 JSON 里，只在 runtime 报错时暴露。
