VSCode插件中未捕获的Promise异常会静默失败，必须在activate函数顶部显式监听process.on('unhandledRejection')，并确保launch.json配置type为"extensionHost"、outFiles路径正确、使用integratedTerminal，否则异常不中断、断点不触发、日志不可见。
VSCode插件中未捕获的 Promise 异常会静默失败
VSCode 插件运行在 Node.js 环境中，但默认不拦截未处理的 Promise 拒绝（unhandledRejection）。这意味着 fetch 失败、vscode.window.showInputBox() 被取消、或异步命令抛出错误时，控制台可能只打印一行警告，插件逻辑却已中断——用户无感知，你也收不到报错。
必须显式监听并处理：
- 在插件激活入口（
activate函数）顶部添加：process.on('unhandledRejection', (reason, promise) => { console.error('Unhandled rejection:', reason); }); - 所有
async命令回调都应包裹try/catch，不要依赖外层兜底 -
vscode.window.withProgress内部的异步操作同样需单独catch，它不自动传播异常
调试时 launch.json 配置不生效导致异常中断失效
插件调试依赖 .vscode/launch.json 中的 type: "extensionHost" 配置。常见错误是：配置了 "stopOnEntry": true 却没设 "outFiles"，或误用 coreclr/node 类型——这会让断点完全不触发，异常直接穿透。
关键项检查清单：
-
"type"必须为"extensionHost"，不是"node" -
"outFiles"应指向编译后 JS 路径，例如["${workspaceFolder}/out/**/*.js"]；若用 TS，确保tsconfig.json中"outDir"与之一致 - 避免
"console": "internalConsole"，改用"integratedTerminal"，否则console.error输出不可见 - 添加
"skipFiles": ["<node_internals>/**"]</node_internals>，防止断点跳进 Node 内部代码
插件上下文丢失导致错误无法定位
VSCode 插件常在多个触发点（命令、事件、WebView）中执行，但错误堆栈里往往只有 extension.js:123 这种模糊位置。根本原因是：TypeScript 编译后 source map 未正确加载，或错误未携带上下文标识。
实操建议：
- 在
tsconfig.json中确认"sourceMap": true和"inlineSources": true同时开启 - 所有顶层
try/catch中，手动附加上下文：catch (err) { console.error(`[command:submitSolution] ${err}`); } - 对关键异步操作使用
vscode.window.setStatusBarMessage设置临时状态，失败时可反推执行路径 - 禁用
"debug.javascript.usePreview": false（旧版调试器），改用新 JS 调试器以获得完整调用链
调试器无法捕获虚拟线程或子进程异常
当插件启动子进程（如调用 child_process.spawn 执行 CLI 工具）或使用 Java/Python 虚拟线程时，VSCode 默认调试器看不到这些线程/进程内的异常——它们运行在独立上下文中，堆栈不会挂载到 Variables 面板。
绕过限制的方法：
- 子进程异常：用
stderr.on('data', chunk => console.error(chunk.toString()))显式捕获输出，并在主进程打日志 - Java 虚拟线程：必须在 JVM 启动参数中加
-Djdk.virtualThreadScheduler.parallelism=1，并启用Exception Breakpoints → Caught Exceptions - Python 子进程：在
launch.json的env中设置PYTHONFAULTHANDLER=1，强制输出崩溃时的完整 traceback
真正难调试的从来不是语法错误，而是那些没被 process.on('unhandledRejection') 捕获、又没在 launch.json 里配对 outFiles 的异步断裂点——它们让错误消失得比日志还快。
