核心是验证装上后功能是否完整可用，需检查插件engines.vscode声明与code --version匹配、Remote-SSH远端vscode-server commit ID是否一致、Node.js版本及调试API支持情况。
VS Code 不同版本的兼容性测试，核心不是“能不能装上”，而是“装上后功能是否完整可用”。很多问题在安装时毫无提示，直到你右键没反应、断点不命中、Remote-SSH 卡在 Starting VS Code Server 才暴露——这时再排查就晚了。直接看关键验证路径。
查插件 engines.vscode 声明是否匹配当前版本
这是最常被跳过的一步。插件能否激活，取决于它 package.json 里 engines.vscode 字段和你本地 code --version 的语义化匹配结果。
- 打开命令面板（
Ctrl+Shift+P），执行Developer: Toggle Developer Tools - 在控制台中粘贴并运行：
vscode.extensions.getExtension("FittenTech.Fitten-Code")?.packageJSON.engines.vscode - 输出类似
"^1.103.0"或=1.68.0"，对照你本地code --version（比如1.118.0）判断是否落在范围内 - 注意：
^1.103.0表示1.103.0 ≤ version ，但不包含 <code>1.102.x；而>=1.68.0就宽松得多
验证 Remote-SSH 是否真能连通，而非只看登录成功
Remote-SSH 连接成功 ≠ 功能正常。它依赖远端 vscode-server 与本地 VS Code 的 commit ID 严格一致，不是版本号一致就行。
- 本地执行
code --version，记下完整输出（如1.118.0 1a5b1a7e3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9） - 远程服务器上检查目录：
ls ~/.vscode-server/bin/，确认是否存在该 40 位 commit ID 子目录 - 若不存在，说明 server 没拉对——离线环境必须手动下载对应 commit ID 的
vscode-server-linux-x64.tar.gz并解压到该路径 - 别信“大版本一致就行”，
1.118.0和1.118.1的 commit ID 完全不同，server 不会复用
检查 Node.js 环境是否满足调试 API 要求
VS Code 调试器底层调用的是本地 Node.js，不是内置 JS 引擎。很多 Web Crypto、Worker Threads 等 API 在低版本 Node 中默认不可用，且不会报错，只静默失效。
- 在调试配置
launch.json中，加一行"console": "integratedTerminal"，启动后立刻在终端里执行node -v && node -e "console.log(!!globalThis.crypto?.subtle)" - 若输出
false，而你用的是 Nodev18.19.0+，则需在runtimeArgs中显式添加--experimental-webcrypto - 若用的是
v19.0+，删掉该 flag 反而更稳——旧版 flag 在新版里可能触发警告甚至拒绝启动 - 务必确认
runtimeExecutable指向的是你期望的 Node 版本，而不是系统默认的/usr/bin/node
真正容易被忽略的点是：VS Code 启动时读取的是 shell 初始化后的环境，但调试器进程不一定继承全部变量。哪怕你在终端里 export NODE_OPTIONS=--experimental-webcrypto 有效，F5 启动仍可能失效——必须把 flag 显式写进 runtimeArgs，且确保重启 VS Code 后生效。
