根本原因是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 指向了编译后路径或缺失源码内容。
-
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}'] - 别同时写
testMatch和testRegex，后者会被忽略，容易白配 - 改完配置必须重启 VSCode（不是重载窗口），否则扩展不会重新读取
