VS Code断点调试难点在于复杂程序中断点失效、变量不可见、执行流混乱及多进程/线程调试配置缺失；需精准配置launch.json的program与cwd、禁用运行时优化、手动插入debugger、为子进程单独设置attach模式。
VS Code 的断点调试本身不难，难的是在复杂程序（多线程、异步调用、跨文件依赖、第三方库介入）里让断点真正停住、看清变量、理清执行流。关键不是“怎么加断点”，而是“断点为什么没触发”“停住了却看不到想要的值”“一跳就飞出业务逻辑”。
断点加了但根本不触发？检查 launch.json 的 program 和 cwd
常见于 Python/Node.js 等解释型语言：你点了左侧行号加断点，代码跑起来却毫无反应。大概率是 VS Code 没运行你认为的那个文件。
-
program必须指向实际入口文件的绝对路径或相对于cwd的正确路径，不能写错大小写或漏掉.py/.js -
cwd（当前工作目录）影响模块导入和相对路径读取——如果项目用import utils但utils.py在父目录，cwd设成项目根才能导入成功，否则断点所在文件根本加载失败 - Node.js 下还要确认
runtimeExecutable是否指向正确的node（比如 nvm 切换版本后路径变了）
停在断点但 variables 面板空或显示 undefined？优先查作用域和优化级别
尤其在 TypeScript 或带 source map 的前端项目中，断点停了，但变量名全灰、hover 看不到值、Debug Console 里 typeof xxx 是 undefined。
- TypeScript 编译时若设了
"sourceMap": true但没配"inlineSources": true，VS Code 可能无法映射原始变量名到生成代码 - Node.js 运行时加了
--optimize-for-size或 V8 默认优化（如函数内联），会导致局部变量被消除——加--nolazy --no-opt启动可绕过 - Python 中使用
exec()或eval()动态执行的代码，断点无法捕获其内部变量；需改用breakpoint()内置函数手动插入
异步逻辑（Promise / async/await / setTimeout）里断点跳得乱？用 debugger; + step into 组合
GUI 界面或事件驱动程序里，光靠行断点容易跳进框架源码（比如 React 的 scheduler.development.js），错过自己写的回调。
- 在关键异步回调开头手动加
debugger;语句（浏览器或 Node.js 均支持），比单纯点断点更可控 - 按
F11（Step Into）时留意右下角状态栏是否显示“正在进入异步调用”——若没显示，说明当前帧已脱离原始调用栈，需在回调函数第一行重新下断点 - Chrome DevTools 兼容模式下启用
Async Call Stack（VS Code 的 Debug 视图右上角齿轮图标里勾选），能让调用栈显示 Promise 链路
多进程/多线程程序（如 Python multiprocessing、Node.js cluster）断点失效？必须为子进程单独配置 attach 模式
主进程断点正常，子进程完全不响应——因为默认配置只 attach 到启动的主进程，子进程是全新实例，没加载调试器。
- Python：在子进程代码开头加
import debugpy; debugpy.listen(5678); debugpy.wait_for_client()，再在launch.json新增一个config，type设为python，request设为attach，port对应监听端口 - Node.js：启动子进程时加
--inspect=9229（端口别和主进程冲突），然后新建一个 Attach 配置，port改成9229 - 切记：子进程调试前，主进程要先暂停或延时，否则子进程可能执行完就退出，来不及 attach
复杂程序的调试瓶颈，往往不在“会不会加断点”，而在于没意识到 VS Code 调试器其实是多个独立进程间的协作系统——每个进程有自己的上下文、符号表和生命周期。漏掉任意一环的配置，断点就只是个摆设。
