断点命中后瞬间继续，根本原因是attach模式未真正连接成功，需确保每个服务配置"use":"attach"、--inspect-brk端口唯一、address设为"localhost"、sourceMap路径精确匹配且configuration名称全局唯一。
断点中断后自动恢复？不是超时，是 attach 模式没配对
VSCode 调试微服务时“断点命中但瞬间继续”，根本不是超时问题，而是 attach 模式下调试器与目标进程未建立稳定连接——它压根没真正 attach 上，只是短暂握手后就断开了。典型现象是：断点红点亮了一下、控制台闪出 Connected to the target VM，接着立刻 resume，Debug Console 里几乎没日志。
- 检查每个 service 的
launch.json配置是否都用了"request": "attach"，而非"launch"；launch模式在微服务场景下基本无效 - 确认服务启动命令中明确包含
--inspect-brk=9229（或对应端口），且该端口未被复用；多个服务必须用不同端口，比如9229、9230、9231 -
address字段不能写127.0.0.1或留空，Docker 容器内调试必须填"address": "localhost"（VSCode 会自动解析为容器可连地址） - 如果服务跑在 Docker 里，确保容器启动时加了
-p 9229:9229等端口映射，且宿主机防火墙没拦截
sourceMap 路径错一个字符，断点就“假命中”
断点看起来生效了（红点实心），但执行不暂停，大概率是 outFiles 或 sourceMaps 配置和实际构建产物不一致。Node.js 调试器靠 sourceMap 把 .ts/.js 映射回源码位置，映射失败就会 fallback 到“假装断在那儿”，其实没 hook 上。
-
outFiles必须精确匹配构建输出路径，比如 TypeScript 编译后文件在dist/下，就得写"outFiles": ["${workspaceFolder}/user-service/dist/**/*.js"]，不能漏掉**或写成src/** - 确保构建时生成了
.map文件（tsc --sourceMap或 webpack 的devtool: 'source-map'），且 .map 文件和 .js 在同一目录 - 如果用
ts-node直接运行，别配outFiles，改用"type": "pwa-node"+"runtimeExecutable": "ts-node"，否则 sourceMap 解析逻辑完全不同
compounds 启动后部分服务断点失效？检查 configuration 名称是否重复
compounds 本身不处理断点同步，它只触发多个 configuration 并行 attach。一旦某个 configuration 名称重复（比如两个都叫 "user-service"），VSCode 会静默覆盖前一个，导致你看到的“部分断点不生效”，其实是那个配置根本没加载。
- 每个
configuration的name字段必须全局唯一，建议按服务名+端口命名，如"user-service:9229"、"order-service:9230" - 启动 compound 前，先单独运行每个 configuration 测试是否能稳定 attach；任一失败，compound 就不可靠
- 不要在
compounds里混用launch和attach类型，统一用attach；混合类型会导致 VSCode 内部状态混乱，断点注册时机错乱
breakOnError 设为 false 会让断点“消失”？不是，是异常被吞了
把 breakOnError 设成 false 不会影响普通断点，但它会让未捕获异常直接崩溃进程，而 VSCode 来不及触发断点。你看到“断点没停”，其实是代码在 hit 断点前就因异常退出了。
- 调试阶段建议保持
"breakOnError": true（默认值），尤其微服务间常有网络异常、JSON 解析失败等未 catch 场景 - 若确实要关，务必配合
"stopOnEntry": false和"console": "integratedTerminal"，否则异常堆栈可能直接刷屏消失 - 更稳妥的做法是启用
exception breakpoints：在 Run and Debug 面板点击「设置」→「Add Exception Breakpoint」→ 勾选Uncaught Exceptions，比依赖breakOnError更精准
