调试单测时“未处理拒绝”不中断，需在launch.json的runtimeArgs中添加"--unhandled-rejections=strict"，使Node.js将未捕获Promise拒绝视为致命错误并触发调试器中断，同时确保Node版本≥15且测试未被框架静默吞掉。
调试单测时“未处理拒绝”不中断，先确认是否启用了 unhandledrejection 捕获
VSCode 默认不会在 unhandledrejection 事件触发时暂停，哪怕你打了断点——它只响应同步断点、debugger 语句或显式配置的异常捕获规则。Node.js 单测（尤其是用 jest 或 vitest）跑在子进程中，拒绝未被 catch 或 await 时，会抛出 unhandledRejection，但调试器默认忽略它。
必须手动开启：打开「运行和调试」侧边栏 → 点击右上角齿轮图标 → 在弹出的 launch.json 配置里，给当前配置加一行：
{
"type": "node",
"request": "launch",
"name": "Debug Tests",
"program": "${workspaceFolder}/node_modules/.bin/jest",
"args": ["--runInBand", "--no-cache"],
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen",
"env": { "NODE_OPTIONS": "--enable-source-maps" },
"skipFiles": ["<node_internals>/**"],
"smartStep": true,
"pauseForSourceMap": true,
"runtimeExecutable": "node",
"outFiles": ["<output_root>/**/*.js"],
"stopOnEntry": false,
"runtimeArgs": ["--unhandled-rejections=strict"] // ← 关键：让未处理拒绝变成致命错误并中断
}
--unhandled-rejections=strict 是 Node.js 15+ 的原生开关，它会让未捕获的 Promise.reject() 直接退出进程，并被 VSCode 调试器捕获为“未处理异常”。没有这行，调试器就当它不存在。
- 旧版 Node.js（--throw-deprecation + 手动监听
process.on('unhandledRejection', ...) -
jest默认吞掉拒绝，加--runInBand是为了防止它 fork 子进程导致调试器失联 - 若用
vitest，program改为"${workspaceFolder}/node_modules/.bin/vitest"，同样加runtimeArgs传参
断点打在 test 文件里却跳过，检查测试运行模式是否绕过了源码
常见现象：你在 test/user.test.ts 里打了断点，启动调试后直接跑完、没停——不是断点失效，是测试框架没执行你写的 TS 文件，而是执行了编译后的 JS 或内存中生成的临时模块。
根本原因有三个：
-
jest默认用ts-jest或babel-jest转译，但不生成 .map 文件，sourceMaps链路断了 -
vitest默认用 esbuild 编译，产物在内存里，没落地.js和.map，VSCode 找不到映射目标 - 测试入口不是你写的
.test.ts，而是框架自动生成的 runner，program指向的是 CLI 脚本而非你的源文件
实操建议：
- 对
jest：确保tsconfig.json启用"sourceMap": true，并在jest.config.ts中配transform: { '^.+\.(ts|tsx)$': ['ts-jest', { isolatedModules: false }] } - 对
vitest：在vitest.config.ts加esbuild: { sourcemap: true }，同时launch.json中补全"resolveSourceMapLocations": ["${workspaceFolder}/**/*.{ts,tsx}"] -
program字段不要指向.test.ts，保持指向 CLI 入口（如node_modules/.bin/jest），靠args控制运行范围（例如["user.test.ts"]）
单测里 setTimeout 或异步钩子导致断点跳过，得关掉 smartStep
smartStep 是 VSCode 的“智能单步”功能，它会自动跳过 node 内部代码和 source map 不匹配的区域。但在单测场景下，它常把 jest 的 beforeEach、afterAll 或 Promise 微任务队列里的回调直接跳过，看起来像断点没生效。
解决方案很简单：在 launch.json 对应配置里显式关掉它：
"smartStep": false,
再配合以下设置提升命中率：
-
"skipFiles": ["<node_internals>/**", "**/node_modules/**"]</node_internals>—— 避免跳进 Jest 底层 -
"console": "integratedTerminal"—— 确保输出可见，方便定位哪条测试卡住 - 如果测试含大量定时器，加
"timeout": 30000防止调试器超时断开
为什么 process.on('unhandledRejection') 断点不触发
你可能在测试文件顶部写了：
process.on('unhandledRejection', (reason) => { debugger; });
结果调试时从不进来——这不是语法错，是事件监听注册得太晚。Jest/Vitest 在加载测试文件前，已经运行了一轮初始化逻辑，部分 Promise 拒绝发生在监听器注册之前。
真正可靠的做法是：在 launch.json 的 runtimeArgs 里加 --inspect-brk，让 Node 进程启动即暂停，然后手动在 DevTools 里设全局断点：
- 按
Ctrl+Shift+P→ 输入Developer: Toggle Developer Tools - 切到
Sources标签 → 左侧找Node.js Runtime→ 展开 → 找process相关脚本 - 在
process.emit或process._fatalException处打通用断点（比监听器更底层）
或者，更直接：别依赖监听器，在测试里主动 await 或 catch 每个可疑 Promise，把“未处理”变成“已处理”，再用 expect(...).rejects.toThrow() 显式断言——这才是单测该有的写法。
最后提醒一句：unhandledRejection 是运行时信号，不是语法错误；VSCode 调试器能抓到它，前提是 Node 版本 ≥ 15、参数开了 strict、且测试没被框架静默吞掉。任何一环断开，它就悄无声息地溜走。
