VSCode调试不自动定位错误，而是通过断点、调用栈和变量检查暴露问题；断点未命中常因未正确attach进程、路径配置错误、sourceMap缺失、异步执行跳过或环境配置不当；变量显示异常源于JS作用域、对象折叠或this指向特性；Debug Console与Terminal执行上下文不同，不可混用；高效调试依赖对执行逻辑的深入理解而非工具本身。
VSCode 调试本身不会“自动定位错误”，它只是把错误现场暴露得更直接——关键在你是否用了断点、是否看了调用栈、是否检查了变量值。
为什么加了断点却没停住？
常见原因不是断点失效，而是调试器根本没 attach 到目标进程，或者代码根本没执行到那行：
-
launch.json里program路径写错，或cwd指向了错误工作目录，导致启动的是旧版本或另一个同名文件 - 用了 TypeScript / Babel 等编译工具，但
sourceMap没开启或路径不对，断点打在源码上，实际运行的是编译后代码 - 异步代码（比如
setTimeout、Promise.then）里设断点，但调试器已跑过那段逻辑——得在入口处提前打断点，再逐步跟进 - 某些环境（如浏览器扩展、Electron 渲染进程）需额外配置
type: "pwa-chrome"或指定webRoot
调试时变量显示 undefined 或值不对？
这不是 VSCode 的 bug，而是 JavaScript 执行上下文和作用域的真实反映：
- 在函数外部看内部
let/const变量，调试器确实读不到——这是语言特性，不是调试器问题 - 对象属性显示为
[Object]是默认折叠，点右侧小箭头展开即可；若想默认全展开，可在settings.json加"debug.inlineValues": true - 修改调试中变量的值（右键 >
Set Value）只影响当前会话，不影响源码，也未必能改变后续逻辑（比如已缓存的闭包引用） - 注意
this指向：在箭头函数里看不到this变量面板，因为它继承自外层作用域
Debug Console 和 Terminal 的输出为什么不一样？
它们根本不在同一个执行环境：
-
Debug Console运行在调试器上下文中，能访问当前断点处所有局部变量、this、闭包，支持直接调用函数（如myFunc()），但不能执行 shell 命令 -
Terminal是独立 shell 进程，运行的是原始命令（如node index.js），不感知断点，也不共享变量作用域 - 常见误操作：在
Terminal里改了代码却忘了保存，或没重启调试会话，导致看到的仍是旧行为 - 想验证某段逻辑是否真被调用？别只看
console.log，在对应行设断点，看调试器是否真停住——日志可能被过滤、缓冲，断点不会说谎
真正快的不是 VSCode，是你对断点位置、调用栈深度、变量生命周期的理解。一个没搞清 async/await 执行顺序的人，哪怕装了十个调试插件，也会在 Promise 链里反复失联。
