vscode-test 是验证调试插件断点稳定性的唯一可行方案，需禁用扩展、动态添加并校验断点、显式设超时、确保 sourcemap 正确映射、清理会话与进程资源。
如何用 vscode-test 验证调试插件在真实环境中的断点稳定性
断点命中失败、单步卡顿、变量刷新延迟——这些问题只在真实 VSCode 环境中复现，单元测试根本抓不到。vscode-test 是唯一能加载完整调试上下文（包括 cortex-debug、cppdbg 或自研 DAP 适配器）并触发实际断点行为的测试路径。
- 必须指定
launchArgs: ["--disable-extensions"]启动干净环境，否则第三方插件（如ESLint的onType模式）会干扰调试器事件循环 - 测试脚本里不能直接调用
vscode.debug.startDebugging()就完事；要等vscode.debug.activeDebugSession非空，且检查session.state === vscode.DebugSessionState.Stopped才算真正停在断点 - 对 RISC-V 或 Cortex-M 类插件，需在
test/integration/下准备最小可复现的.elf文件，并确保launch.json中program路径指向该文件，否则vscode-test会静默跳过调试启动 - 超时控制必须显式设为
timeout: 15000：DAP 连接 OpenOCD 或 J-Link Server 可能因硬件响应慢而卡住，不设 timeout 会导致 CI 流水线挂死
为什么断点灰掉（unbound）？检查 sourceMap 和 outFiles 的真实映射关系
你在 extension.ts 里打的断点变成灰色，不是代码没编译，而是调试器找不到源码与生成 JS 的对应关系。VSCode 插件调试依赖两层映射：TS 编译产出的 .js.map，以及 launch.json 中 outFiles 对这些 map 文件的扫描路径。
-
tsconfig.json必须含"sourceMap": true和"outDir": "./out"，且编译后out/extension.js同级存在extension.js.map -
launch.json的outFiles字段不能写成"./out/**/*.js"—— 它只匹配 JS 文件，不递归解析 map；应改为"./out/**/*.js", "./out/**/*.js.map" - 如果用了 Webpack 打包，
devtool: "source-map"不够，必须加output.devtoolNamespace: "my-extension"，否则多个插件的 map 会冲突导致断点失效 - Git 忽略了
out/目录？调试器就找不到 map 文件。检查.gitignore是否含/out行，临时注释掉再试
集成测试中模拟用户操作：避免硬编码断点位置
测试脚本里写 editor.insertText(new Position(10, 0), "debugger;") 再运行，看似能测断点，但实际不可靠——不同芯片的调试协议对 inline debugger 支持程度不同，Cortex-M85 可能忽略它，RISC-V 则可能触发异常中断。
- 正确做法是用
vscode.debug.addBreakpoints([new vscode.SourceBreakpoint(new vscode.Position(line, column))])动态添加断点，然后验证breakpoints.length > 0且breakpoints[0].verified === true - 不要假设断点一定在第 5 行；先用
vscode.workspace.openTextDocument()读取目标文件，用正则定位函数起始行，再计算偏移量 - 测试结束后必须调用
vscode.debug.removeBreakpoints()，否则残留断点会影响下一轮测试，尤其在 CI 多任务并发时容易误触发 - 对 SVD 寄存器可视化类功能，别只测 UI 是否渲染；要抓
vscode.debug.activeDebugSession.customRequest("readMemory", { address: "0x40023800", count: 4 })的返回值是否符合预期
CI 流水线中识别调试插件的隐性崩溃
插件没报错、测试全绿，但用户反馈“调试几次后编辑器卡死”——这种问题在本地很难复现，却会在 CI 的长时间运行中暴露。关键不是看日志有没有 error，而是监控进程资源和 DAP 通信状态。
- GitHub Actions 中加一步：
ps aux --sort=-%cpu | head -n 5，捕获测试末期 CPU 占用最高的进程；若Extension Host持续 >70%，说明调试器未释放资源 - 在测试 teardown 阶段执行
vscode.debug.stopDebugging()后，等待 2 秒再检查vscode.debug.activeDebugSession是否为undefined；不为空即代表会话泄漏 - 对使用 OpenOCD 的插件，在测试开始前运行
lsof -i :3333 | wc -l（默认 OpenOCD 端口），结束后再查一次，数值不归零说明子进程未被 kill - 禁用所有非必要扩展（
--disable-extensions）不是万能的；某些调试插件依赖ms-vscode.cpptools提供的符号解析能力，此时要用--extensions-dir指向一个只含这两个插件的精简目录
Extension Host 进程内存回落、OpenOCD 进程退出、断点列表清空——这三个信号比任何断言都更能说明问题。
