根本原因是jest默认并行运行测试，而vscode调试器只能attach主进程；必须在launch.json中显式添加--runinband参数，并确保jest.config.js中maxworkers设为1或删除，同时tsconfig.json开启"sourcemap":true和"inlinesources":true。

VSCode点“Debug Test”没反应，根本原因是没配 --runInBand

Jest 默认并行运行测试，而 VSCode 的 Node.js 调试器只能 attach 到主进程。不加 --runInBand，断点要么不触发，要么随机停在某个子进程里，你完全感知不到。

这不是插件问题，也不是断点打错了——是 Jest 进程模型和调试器不兼容导致的静默失败。

• launch.json 中必须显式传参 --runInBand（不能只靠插件自动加）
• 别信 "autoAttachChildProcesses": true，它在 --runInBand 下无意义，还可能干扰
• 如果用了 jest.config.js 里的 maxWorkers，务必设为 1 或删掉，否则和 --runInBand 冲突

断点停在空白行或 __tests__/xxx.js 里，90% 是 sourceMap 没对齐

TS 项目里断点跳转错位，不是 VSCode 识别错了，而是 source map 指向了编译后路径或缺失源码内容。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

• tsconfig.json 必须同时开启："sourceMap": true 和 "inlineSources": true
• 用 ts-jest 的话，jest.config.js 的 transform 规则要覆盖 .ts 文件，且不能漏掉 ^.+\.tsx?$ 这种通配
• 别在 setupFilesAfterEnv 里 throw 错误——它会在调试启动阶段就失败，导致断点根本没机会加载

点击“Debug Test”后终端一闪而过，去 Output → Testing 看真实命令

VSCode 测试面板只是 UI，真正执行的是后台拼出的命令。点不动、卡住、没输出，第一步不是重装插件，而是看它到底发了什么。

• 打开 Output 面板 → 切到 Testing 标签页，你会看到类似：npx jest --runInBand --testNamePattern="should submit form" src/components/Form.test.tsx
• 复制这整条命令，粘贴到终端手动执行，观察是否报错（比如 Cannot find module 'react' 就说明 setupFilesAfterEnv 或 transform 缺配置）
• 如果终端能跑但 VSCode 点不动，大概率是 jest.pathToJest 在设置里写死了错误路径（比如填了 npx jest，应改为 ./node_modules/.bin/jest）

测试文件旁没出现“Debug”按钮，先确认 testMatch 是否匹配到它

Orta.vscode-jest 扩展默认只扫描 **/*.test.* 和 **/__tests__/** 下的文件。你的测试文件叫 Button.unit.tsx 或放在 src/tests/ 下？那它压根不会被发现。

• 在 jest.config.js 中显式配置 testMatch，例如：['<rootdir>/src/**/*.{test,spec}.{js,jsx,ts,tsx}']</rootdir>
• 别同时写 testMatch 和 testRegex，后者会被忽略，容易白配
• 改完配置必须重启 VSCode（不是重载窗口），否则扩展不会重新读取

复杂点在于：所有环节都得对齐——Jest 的配置决定“跑哪些”，VSCode 的 launch.json 决定“怎么跑”，tsconfig 决定“断点停在哪”。少一个，调试就变成盲调。