应将package.json中engines.vscode设为">=1.85.0
插件开发时遇到“Extension is not compatible with Code x.x.x”报错，不是代码写错了，而是package.json里engines.vscode字段锁死了支持范围——它决定你的插件能被哪些 VSCode 版本加载，而不是“能不能跑”。
怎么改 engines.vscode 才既安全又覆盖广
宽松不等于随便写。写太宽（比如"vscode": "*"）会被 Marketplace 拒绝上传；写太死（比如"^1.102.0"）会导致降级用户装不上。
- 推荐写法：
"vscode": ">=1.85.0 —— 明确下限（保证 API 可用），上限略高于当前最新稳定版（VSCode 1.118 已发布，留一版缓冲） - 若需兼容旧版（如内部仍用 1.79），可写：
"vscode": ">=1.79.0 ，但必须手动验证是否调用了 1.79 不支持的 API（比如<code>workspace.findFiles在 1.83+ 新增了useGitIgnore选项） - 避免用
^或~——它们对1.x主版本无效，^1.85.0实际等价于>=1.85.0 ，风险不可控
本地调试时如何快速验证多版本兼容性
不能只靠“我本地是 1.118 就行”，得实测目标环境。VSCode 官方提供离线二进制包，无需重装系统级应用。
- 从 VSCode 官网历史版本页 下载目标版本（如
1.85.2、1.102.3）的.zip/.tar.gz包 - 解压后直接运行
Code.exe（Windows）或Visual Studio Code.app/Contents/MacOS/Electron（macOS），它会使用独立配置目录，不影响主编辑器 - 在该实例中执行
Extensions: Install from VSIX，装你打包好的.vsix，观察控制台是否有TypeError: xxx is not a function——这才是真兼容，不是“不报错就完事”
Remote-SSH 插件开发必须注意的双端版本耦合
Remote 类插件不是普通前端扩展：它分本地 UI 部分 + 远端vscode-server部分。二者版本必须严格一致，否则连接卡在Starting VS Code Server。
- 开发时，
vscode-server的构建版本由vscode源码中的commit哈希决定，不是你engines.vscode写的值——所以不能只改package.json - 测试 Remote 功能，必须用对应 VSCode 版本的官方构建包启动（不能用
npm run watch起的 dev 实例），否则远端拉取的 server 版本和本地不匹配 - 若要支持跨版本 Remote（比如本地 1.118 连远端 1.102 的 server），需在插件中显式指定
serverApplicationPath并预置对应 commit 的 server 二进制，这属于高级定制，非常规做法
最容易被忽略的是：改完engines.vscode后，本地vsce package生成的.vsix仍会校验该字段——但 Marketplace 上传时还会二次校验。如果你面向企业内网分发，务必用真实目标版本的 VSCode 手动安装测试，别信“没报错”就是兼容。
