VS Code调试核心是理解断点类型与变量求值时机；需启用sourceMaps、正确配置launch.json、合理使用Watch和Debug Console，并重视闭包变量检查。
VS Code 调试不是靠“点点点”凑出来的，核心在于理解断点类型与变量求值时机——多数卡顿、跳过、值为空的问题，都出在断点位置或调试器未加载源映射上。
断点加在哪才真正生效
函数入口、异步回调内部、Promise.then() 链里加断点，常常不触发。因为 JavaScript 调试器默认只在“已解析且可执行”的代码行设断点，而转译（如 TypeScript、JSX）或打包（webpack/vite）后，实际运行的是 dist 或 .js 文件，原始源码行号已失效。
- 确保启动调试时启用
sourceMaps: true（在launch.json的configurations中） - TypeScript 项目必须编译输出
.map文件，且tsconfig.json中"sourceMap": true和"inlineSourceMap": false（后者易导致断点偏移） - React/Vue 项目用 vite 启动时，
launch.json的url应指向http://localhost:5173，而非本地文件路径；否则断点无法绑定到源码 - 动态生成的代码（如模板字符串拼接的函数、
eval()内容）默认不支持断点，需显式加debugger语句并配合skipFiles排除 node_modules
变量监控不是“看一眼就完事”
Watch 面板输入 user.profile.name 却显示 undefined？不是变量不存在，而是当前作用域下 user 尚未赋值，或该表达式在断点暂停前根本没执行到——Watch 是实时求值，不是快照。
- 右键变量 →
Add to Watch最可靠；手动输表达式时，避免含副作用操作（如arr.pop()），它会在每次刷新 Watch 时真实执行 - 想查异步状态？在
await fetch(...)后设断点，再在 Watch 中输response?.status；别在fetch()调用行就盯response，它此时还是undefined - 对象深层属性监控失效？改用
JSON.stringify(user)或展开user后逐级右键 →Store as global variable（临时变量名如tempUser），再 WatchtempUser.profile.name
调试控制台（Debug Console）和终端（Terminal）根本不是一回事
在 Debug Console 里输 console.log(x) 看不到输出？不是 bug，是设计如此：Debug Console 执行环境是当前暂停帧的作用域，console.log 输出默认进浏览器 DevTools 控制台或 Node.js stdout，不会回显在 VS Code 的 Debug Console 面板里。
- Debug Console 支持直接调用当前作用域函数、修改变量值（如
count = 99），但改完要按F5继续才能生效于后续逻辑 - 想看
console输出？打开浏览器 DevTools（F12）→ Console 标签页；Node.js 调试则看 VS Code 下方DEBUG CONSOLE面板顶部的“Console”选项卡（不是“Debug Console”面板本身） - 误在 Debug Console 输入
process.exit()？会直接终止调试进程——这里没有沙箱，所有命令直通运行时
最常被忽略的一点：断点命中后，不要急着点“继续”；先展开左侧 VARIABLES 面板里的 Closure、Global，很多状态异常其实藏在闭包变量里，而不是当前函数参数中。
