VSCode调试需主动设断点、观变量、控执行流；在可执行同步行加断点（红点），F5启动（需launch.json）；断点空心则检查sourceMaps；WATCH栏查深层变量和error.stack；CALL STACK确认函数调用路径。
VSCode 的调试功能不是“点一下就自动修 bug”，它需要你主动设置断点、观察变量、控制执行流——但只要配对关键步骤，定位错误比 console.log 快得多。
怎么加断点并启动调试
断点是调试的起点，不是加在任意行都有效：函数未被执行、异步代码未进入回调、或代码被优化跳过时，断点会“不命中”。确保你在真正会运行的同步逻辑行上单击行号左侧空白处，出现红点；然后按 F5 启动调试（前提是已有可用的 launch.json 配置）。
- 没
launch.json？按Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入 “Debug: Open launch.json”，选择对应环境（如 “Node.js” 或 “Python”） - 使用 TypeScript 或前端项目时，
launch.json中的program或url字段必须指向可执行入口（如./dist/index.js或http://localhost:3000），而不是源码文件 - 断点变为空心红点？说明 VSCode 没找到对应源码映射——检查
sourceMaps是否设为true，且构建输出中包含.map文件
调试时怎么看变量和执行状态
左侧面板的 “VARIABLES” 区域显示当前作用域变量，但它默认只展开一层对象。深层嵌套值（比如 res.data.items[0].name）不会自动展开，也不能靠鼠标悬停实时查看——你需要在 “WATCH” 栏手动添加表达式。
- 在 “WATCH” 面板点击 “+” 号，输入
error.stack查看完整错误堆栈，比终端里截断的更全 - 悬停变量名只能看到基础类型值；对
Promise、Proxy或大型数组，悬停常显示[object Promise]或Array(10000)，此时必须依赖 WATCH 或 “DEBUG CONSOLE” 输入表达式求值 - “CALL STACK” 面板能帮你确认是否进了预期函数——比如点击事件没触发，可能卡在事件绑定前，或监听器被重复移除
常见调试失败原因和绕过方法
断点不生效、调试器直接退出、或者控制台报 Cannot connect to the target，多数不是 VSCode 本身问题，而是运行时与调试协议不匹配。
- Node.js 版本太新（如 v20+）？某些旧版
node-debug扩展已废弃，改用内置的Node.js调试器，并确保launch.json中runtimeExecutable未硬编码旧路径 - 前端项目用 Vite / Webpack Dev Server 启动后调试失败？不要用 “Launch Program” 模式，改用 “Attach to Process” 或配置
url+webRoot的 “Chrome” 或 “Edge” 调试器 - 调试 Python 时提示 “ModuleNotFoundError”？检查
python.defaultInterpreterPath是否指向虚拟环境内的python，而非系统全局路径
真正卡住的往往不是“怎么开调试”，而是“断点加在哪”和“变量从哪来”——多看 CALL STACK 和 DEBUG CONSOLE，少依赖直觉。很多看似随机的报错，其实只是上一个异步操作的 catch 被吞掉了，而调试器能直接带你跳进那个被忽略的 catch 块里。
