必须用Debug模式（虫子图标）启动单测，配置类型须为Jest/Mocha/Vitest专用配置；TypeScript项目需启用sourceMap、正确映射路径并勾选WebStorm中Enable source maps选项。
运行单测时断点不触发？先确认调试模式是否启用
WebStorm 默认用 Run 执行测试（绿色三角图标），这不会启动 JS 调试器，断点只是摆设。必须用 Debug 模式（虫子图标）启动单测，且配置类型必须是 Jest、Mocha 或 Vitest 等对应测试框架的专用配置，不是 JavaScript Debug —— 后者只适用于浏览器页面，对 Node.js 环境下的测试无效。
为什么 Jest 单测断点打在 .ts 文件里却停不住？
常见于 TypeScript 项目：断点设在 src/ 下的 .ts 文件，但 Jest 实际执行的是编译后的 .js（或内存中生成的代码），若 source map 配置缺失或路径映射失败，WebStorm 就无法将断点“绑定”到运行时位置。
- 确保
tsconfig.json中"sourceMap": true已启用 - Jest 配置（
jest.config.js或package.json中的jest字段）需包含collectCoverageFrom和sourceMaps: 'both'（或至少'inline'） - WebStorm 的 Jest 运行配置里，务必勾选
Enable source maps（路径：Run → Edit Configurations → Jest → 勾选该选项） - 避免在
dist/或lib/目录下设断点——那不是源码，WebStorm 无法还原变量名和作用域
单测里异步逻辑（Promise / await）断点跳过？检查执行上下文
在 it() 或 test() 回调内设断点，但执行时直接跳过，大概率是因为 Jest 默认以异步方式运行测试，而断点所在行尚未被 V8 调度执行，或已被优化跳过。
- 不要把断点设在
await行本身（如await fetch(...)），而是设在await后的第一行可执行语句上（如const data = await ...;下一行） - 确保测试函数声明为
async，且it('...', async () => { ... })写法正确；否则 Jest 可能忽略await，导致断点落空 - 如果用了
setTimeout或setInterval，断点可能落在不同任务队列中，建议改用jest.runAllTimers()同步推进后再设断点 - 禁用 Jest 的
--runInBand以外的并行模式（如--maxWorkers=2），多进程下 WebStorm 无法稳定 attach 到所有 worker 的调试上下文
Vitest 单测调试失败？注意端口与自动注入机制
Vitest 在 --mode test 下默认不开启调试端口，WebStorm 无法连接。它不像 Jest 那样通过 Node.js 子进程暴露 --inspect，而是依赖 Vitest 自身的 debug 模式。
立即学习“Java免费学习笔记（深入）”；
- 运行配置类型必须选
Vitest（不是Node.js或npm），且Command line options栏填入--debug（Vitest v2+ 支持） - 确保
vitest.config.ts中未设置threads: false—— 若禁用多线程，调试器可能无法捕获子任务断点 - 断点不能设在
describe()外层（如模块顶层），必须落在it()、test()或其回调函数内部 - Vitest 的 HMR 热更新会重载测试模块，已设断点可能失效；调试时建议关闭 HMR（
server.hmr: false）或手动刷新测试进程
最易被忽略的一点：WebStorm 的 Jest 或 Vitest 插件必须处于启用状态（Settings → Plugins → 检查 Jest 和 Vitest Support 是否勾选），否则即使配置全对，IDE 也识别不出测试文件结构，断点根本不会注册进调试协议。
