不是配置错，而是vscode调试器对await暂停有延迟或跳过倾向；需用node类型启动器、确保sourcemaps正确、避免在promise构造函数内断点、通过debug console主动求值查看promise结果。
断点打在 async 函数里却不停，是不是配置错了？
不是配置错，是 VSCode 默认调试器对 await 的暂停行为有延迟或跳过倾向。关键在于确保使用的是 Node.js 原生调试协议（node 类型启动器），而非旧版 node2 或直接运行脚本。VSCode 1.70+ 默认启用 sourceMapPathOverrides 自动映射，但 TypeScript 编译或打包后的路径不匹配时，断点会失效。
- 确认
launch.json中type是"node"，且request为"launch"或"attach" - 若用
ts-node调试，必须加"runtimeArgs": ["-r", "ts-node/register"]，并设"sourceMaps": true - 避免在
Promise构造函数内部打断点——V8 引擎可能因优化跳过，优先打在await行或async函数首行
await 后的变量值显示为 undefined 或 Pending 怎么办？
这是调试器尚未完成 Promise 解析导致的视觉延迟，并非代码错误。VSCode 的 Variables 面板默认只显示当前执行上下文的同步值，异步状态需主动展开或切换到 Call Stack + Debug Console 查看。
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 在 Debug Console 中直接输入变量名（如
result）回车，可强制触发Promise的then回调并输出 resolved 值 - 右键 Variables 面板中的 Promise 对象 → “Re-evaluate” 可刷新状态
- 若始终卡在
Pending，检查是否漏了await（比如写了fetch(...)没await），此时变量类型确实是Promise而非实际值
为什么 setTimeout 或 fs.promises.readFile 里的断点不触发？
因为这些属于 microtask 或 macrotask，调试器默认不会在事件循环下一帧自动停靠。你得让断点落在「可被同步捕获的执行位置」，而不是纯回调注册处。
-
setTimeout(() => { debugger; }, 100)不可靠——debugger语句可能被优化掉，且 VSCode 不保证在定时器回调中激活断点 - 正确做法：把逻辑提取成
async函数，在调用处await并打断点，例如：async function loadFile() {<br> const data = await fs.promises.readFile('a.txt', 'utf8');<br> return data; // 在这行打断点<br>} - 对
process.nextTick或queueMicrotask，同样建议包裹进async函数再await，避免依赖事件循环调度时机
调试 Promise.all 时如何查看单个失败项的错误？
Promise.all 一出错就短路，错误堆栈常指向 Promise.all 调用点，而非具体哪个 Promise 拒绝。需要手动展开或改用更透明的写法。
- 在 Debug Console 中执行
Promise.allSettled([...])替代Promise.all([...])，返回数组含每个 Promise 的{ status, value/error } - 若坚持用
Promise.all，可在每个子 Promise 后加.catch(e => { console.error('item failed:', e); throw e; })，让错误带上下文输出 - VSCode 的 Breakpoints 面板里勾选 “Uncaught Exceptions”，能捕获未处理的 Promise rejection，但注意它会中断所有未 catch 的 reject，包括测试中故意抛的
