VSCode调试Jest需同时满足launch.json配置--runInBand、tsconfig.json启用sourceMap和inlineSources、Orta插件正确设置rootPath和pathToJest，缺一断点即静默失效。
VSCode 调试 Jest 测试不是“装个插件就完事”，核心卡点在 launch.json 配置、source map 映射和 Jest 启动模式三者是否对齐——多数断点不命中、跳转错行、调试器卡在空行的问题，都源于其中一环没对上。
launch.json 必须用 --runInBand 启动 Jest
默认 Jest 会开多个子进程并行跑测试，而 VSCode 的 Node.js 调试器只能 attach 到主进程。不加 --runInBand，断点根本不会被触发，或者只在某个随机子进程里停住（你完全感知不到）。
-
program字段推荐写成"${workspaceFolder}/node_modules/.bin/jest"（macOS/Linux）或"${workspaceFolder}/node_modules/jest/bin/jest.js"（Windows），避免依赖全局jest命令 -
args至少包含"--runInBand"；如需调试当前文件，补上"--runTestsByPath", "${file}" - 别用
runtimeArgs+--inspect-brk组合——它会让调试器卡在 Jest 入口，徒增手动 F5 次数 - 加
"autoAttachChildProcesses": true是冗余的，--runInBand下无子进程可 attach
TS 项目断点失效？检查 sourceMap 和 inlineSources
断点显示在编译后 JS 文件、空白行或 __tests__ 外部，基本是 source map 路径没解析对。VSCode 不读 tsconfig.json 里的 outDir，只认 sourceMap: true + inlineSources: true 这一对组合。
-
tsconfig.json中必须有："sourceMap": true和"inlineSources": true（后者关键，否则 map 文件路径容易脱靶） - 如果用了
ts-jest，确认其版本与 TS 版本兼容；v29+ 对inlineSources更敏感 - 删掉
.vscode/launch.json里所有自定义outFiles或sourceMaps字段——VSCode 现在能自动处理 inline source map - 重启 VSCode，不是重载窗口，是彻底退出再打开，否则旧缓存可能干扰 source map 加载
Orta.vscode-jest 插件要配 jest.rootPath 和 jest.pathToJest
插件图标不亮、右键没 “Debug Test”、状态栏无 Jest 图标，大概率是插件找不到 Jest 配置入口。它不靠 package.json 里的 test script，而是直接读 jest.config.js 或 jest.config.ts，且对路径非常挑剔。
- 在
.vscode/settings.json中显式设"jest.rootPath": "./"（不能留空，也不能写"."） - 若项目用 pnpm，配
"jest.pathToJest": "pnpm jest"；用 npm/yarn 就写"npx jest"（注意引号） - 禁用其他 Jest 相关插件，比如 “Jest Test Explorer” 或 “Jest Runner”——它们和 Orta 插件抢
debugger协议，导致断点注册失败 - 配完必须重启 VSCode，不是重载，是 kill 进程再启
最易忽略的是：Jest 调试不是“启动即通”，而是 launch.json、tsconfig.json、插件配置三者必须同时满足条件。少一个，断点就静默失效——它不会报错，只会假装没看见你点的红点。
