CI/CD 中无法真正调试 VSCode 插件，因其无图形界面、无交互且资源受限；所谓“集成调试”实为在 CI 运行可复现的集成测试，并通过 vscode-test 统一启动参数实现本地一键 attach 调试。
CI/CD 流水线里不能直接运行 VSCode 插件的“调试会话”，但可以复用其调试能力做集成测试验证——关键在于用 vscode-test 启动真实 VSCode 实例，并注入 --inspect 参数供外部调试器连接（仅限本地或调试专用环境）。
为什么不能在 CI 中真正“调试”插件
CI 环境通常无图形界面、无用户交互、资源受限，VSCode 的图形化调试器（如断点、变量监视、调用栈）无法启动。所谓“集成调试”，实质是：在 CI 中运行能触发插件逻辑的集成测试，并确保该过程可被本地复现、可附加调试器排查问题。
- GitHub Actions / GitLab CI 默认使用 headless 模式运行 VSCode，不支持 UI 调试器
-
vscode-test启动的是 Code-OSS 或 VSCode CLI 版本，仅支持命令行参数控制（如--inspect），不开放 DevTools - 若强行启用
--inspect并暴露端口，在 CI 中既无客户端连接，又可能因防火墙/网络策略失败
如何让 CI 测试具备“可调试性”
核心思路是：保证本地与 CI 执行的是同一套测试逻辑和同一套启动参数，只在本地额外开启调试端口。这样当 CI 报错时，你能在本地一键复现并打断点。
- 在
test/runTest.ts中统一构造launchArgs，例如：['--disable-extensions', '--no-sandbox', '--disable-gpu'] - CI 中保持默认行为，不加
--inspect；本地运行时通过环境变量控制，例如：NODE_OPTIONS='--inspect=9229' npm run test - 确保
vscode-test下载的 VSCode 版本与本地开发版本一致（通过INSIDER_VERSION或VSCODE_VERSION环境变量锁定） - 在
package.json中定义两个脚本："test:ci"（纯执行）和"test:debug"（带 inspect）
GitHub Actions 中复现调试环境的关键配置
不是为了在 Actions 里真调试，而是为了让日志、超时、扩展加载行为与本地完全一致，避免“本地过 CI 报错”这类陷阱。
- 使用
runs-on: ubuntu-latest时，显式安装相同 Node.js 版本（如node-version: '22.x'），避免vscode-test内部依赖不兼容 - 禁用所有非必要扩展：
launchArgs: ['--disable-extensions', '--disable-workspace-trust']，否则 CI 可能因扩展初始化失败而卡住 - 设置足够长的超时：
timeoutMinutes: 15，因为 CI 启动 VSCode + 加载插件 + 运行测试比本地慢 2–3 倍 - 捕获完整日志：在
runTests()失败后，打印process.env.VSCODE_LOGS对应路径下的日志（需提前挂载或压缩上传）
容易被忽略的调试断点失效点
即使你在本地成功 attach 上了调试器，也可能发现断点不命中——这不是配置问题，而是 VSCode 插件运行机制导致的。
- 插件代码经 webpack 打包后生成
out/目录，调试器需映射源码（sourceMapPathOverrides在launch.json中必须配对out/**→${workspaceFolder}/**） - VSCode 插件主进程（extensionHost）和测试进程（testRunner）是两个独立 Node.js 进程，
--inspect只作用于启动它的那个进程；若想调试插件本身，要 attach 到 extensionHost；若想调试测试逻辑，要 attach 到 testRunner - CI 中
vscode-test默认用fork启动子进程，而 fork 不继承--inspect参数，所以即使加了参数，插件进程也不会被监听
