根本原因是本地验证和ci流程不一致；应统一构建验证逻辑，本地用vsce package+手动安装测试，ci复用npm test脚本并headless运行，通过devcontainer固定node/vscode版本避免漂移。
插件开发测试反馈慢，根本原因是本地验证和 CI 流程不一致，导致每次改完代码都要手动打包、重装、重启 VSCode 才能看到效果。真正能缩短周期的不是加机器，而是让本地调试和 CI 共享同一套构建+验证逻辑。
vsce package 和 vsce publish 命令别混用
vsce package 只生成 .vsix 文件，不上传；vsce publish 会自动打包并推送到 marketplace。CI 中若误用 publish，不仅暴露 token，还会污染正式版本号。本地测试阶段必须只用 package，CI 的发布阶段再单独走 publish。
- 本地测试流：改代码 →
vsce package→code --install-extension ./my-ext-1.0.0.vsix→ 启动新窗口验证 - CI 验证流：运行
vsce package后，立刻用code --install-extension在 headless 模式下加载并执行 smoke test - CI 发布流：仅当
main分支打 tag（如v1.2.0）时，才执行vsce publish，且必须校验package.json#version与 tag 严格匹配
GitHub Actions 里复用本地 tasks.json 的 test 脚本
VSCode 插件项目通常在 package.json 里定义 "scripts": { "test": "npm run compile && npx vscode-test ..." }。CI 不该另写一套逻辑，而应直接调用这个 npm test —— 和你在命令面板里选 “Run Test” 用的是同一个命令。
- 确保
vscode-test的--extensionDevelopmentPath指向当前工作目录，而非打包后的.vsix，否则测的是旧代码 - CI 中禁用 GUI：添加
--headless参数，避免因无显示环境失败 - 测试超时设为 120 秒以上，CI 环境比本地慢，尤其首次下载 VSCode 二进制时
用 devcontainer.json 统一开发与 CI 的 Node.js / VSCode 版本
本地用 Node.js 18，CI 用 20，或者本地 VSCode 是 1.89，CI 下载的是 1.90，都可能导致 vscode-test 启动失败或 API 行为不一致。最省事的方式是把开发环境容器化，并让 CI 复用同一镜像。
- 在
.devcontainer/devcontainer.json中固定"image": "mcr.microsoft.com/vscode/devcontainers/typescript-node:18" - GitHub Actions 使用相同基础镜像：
uses: actions/checkout@v4后，直接docker run --rm -v $(pwd):/workspace ...运行测试 - 关键点：CI 中不要用
setup-node，也不要用setup-vscode，这些动作引入的版本不可控
最难绷的是版本漂移——你以为改的是插件逻辑，其实卡在 vscode-test 加载了错误版本的 VSCode 内核，或者 vsce 用新版打包后，旧版 VSCode 解析 package.json 字段失败。所有环境变量、Node 版本、VSCode 二进制路径，必须显式声明，不能依赖“系统默认”。
