VSCode断点需代码实际执行且在调试器识别上下文中才生效；须启动调试会话、正确配置launch.json、加在可执行语句、启用sourceMap、确保sourcemap路径映射准确。
断点加在哪才真正生效
VSCode 的断点不是加了就停，得看代码是否被实际执行、是否在调试器能识别的上下文中。比如在 Node.js 里对未被 require 的模块加断点，或在浏览器中对动态 eval 里的代码加断点，大概率不会命中。
实操建议：
- 确保已启动调试会话（按
F5或点击调试图标），且配置了正确的launch.json类型（如node、pwa-chrome） - 断点只能加在可执行语句上：不能加在空行、注释行、对象字面量顶层、
import声明行（ESM 模块中部分环境不支持） - TypeScript 项目必须确认
sourceMap为true，否则断点会落在编译后的.js文件上，和源码错位 - 前端项目若用 Vite / Webpack Dev Server，需检查是否启用了
devtool: 'source-map'或对应 sourcemap 配置
debugger 语句和 UI 断点行为不一致？
debugger 是 JS 原生命令，由运行时直接触发；而 VSCode 点击行号边加的断点，依赖调试器注入和 sourcemap 映射。两者触发时机、作用域、甚至是否启用都可能不同。
常见错误现象：
-
debugger在生产构建后没被移除，导致线上卡死 - UI 断点显示“未绑定”灰色图标 → 通常因为代码未加载、sourcemap 缺失、或路径映射错误（
webRoot配置不对） - 同一行加了 UI 断点又写了
debugger，实际只停一次，但容易误判是“断点失效”
参数差异：launch.json 中的 skipFiles 会同时跳过 debugger 和 UI 断点，比如默认跳过 **/node_modules/** 和 **/lib/** 下的文件。
变量值看不准？别只盯“Variables”面板
VSCode 调试器默认展示的 Variables 面板只展开一层，深层嵌套对象、异步状态、闭包变量经常“看起来是空的”或“显示 [Object]”，但这不代表值不存在或没初始化。
实操建议：
- 把鼠标悬停在代码中的变量名上，能直接看到当前值（支持展开嵌套、查看
Promise状态） - 在
Watch面板手动输入表达式，比如user.profile?.address?.city或Array.from(map.keys())，比靠展开更可靠 - 注意
this的指向：在箭头函数里this不变，在普通函数里可能已丢失，Watch 里输this看到的未必是你预期的对象 - 异步代码中，
await后的变量值要等暂停在下一行才能看到；停在await行时，右侧变量区域显示的是“等待前”的状态
单步执行（Step Over/Into）踩坑最多的地方
很多人以为 F10（Step Over）一定不进函数、F11（Step Into）一定进，但在实际工程里，这个“进不进”受 sourcemap、内联函数、编译优化、甚至调试器版本影响极大。
典型问题：
- 按
F11却跳进了node_modules里的代码 → 检查launch.json中是否漏配skipFiles，或用了**/node_modules/**但路径匹配不准确 - 按
F10却意外进了某个工具函数（如 Lodash 的map）→ 这个函数可能被内联或 sourcemap 映射到了调用处，本质仍是“单步执行当前行”，只是视觉上像跳进去了 - React/Vue 组件中单步跳转混乱 → 框架编译后生成大量代理逻辑，建议优先用
React Developer Tools或Vue Devtools配合断点，而不是强求单步跟透 JSX 渲染链
性能影响：开启调试器本身会让 JS 执行变慢，尤其大量 console.log 或频繁触发断点时，Step Into 可能卡顿明显，此时换用 Step Over + Watch 更高效。
复杂点在于：断点位置、sourcemap 质量、运行时环境三者必须对齐，缺一不可。哪怕只有一项配置偏差，就可能表现为“断点灰了”“变量为空”“单步飞掉”。调试器不是万能的，它只是帮你观察程序快照的工具——别让它替你理解业务逻辑。
