断点变空心、f10/f11跳行的根本原因是调试器未与源码精确映射，主因是source map未生效或编译产物被优化：前端需确保webroot与sourcemap路径匹配且构建生成.map文件；c++项目须用-g -o0编译并验证debug_info；node.js必须用--inspect-brk启动并配置pwa-node调试器。
断点变空心、F10/F11跳行：不是代码错了，是调试器没对上源码
VSCode 里按 F10 却直接从 if 条件跳到 else 分支末尾，或断点打在 console.log() 上却变成空心圆——这不是你漏写了逻辑，而是调试器失去了与源码的精确映射。根本原因通常只有两个：source map 没生效，或编译产物被优化过。
launch.json 中 webRoot 和 sourcemaps 必须同时配对生效
前端项目（Vue/React/Vite）断点漂移，90% 出在 webRoot 和 sourcemap 不匹配。调试器靠这两者把 dist 里的 JS 行号反查回 src 里的原始位置。
-
webRoot必须指向开发服务器实际服务的根路径，比如"${workspaceFolder}"或"${workspaceFolder}/dist"，不能写成"./src" -
sourcemaps需显式设为true，且仅当构建工具真生成了.map文件才有效；Vite 用户检查vite.config.ts中build.sourcemap是否为true - Webpack 用户避免用
devtool: 'eval'，改用'source-map'或'inline-source-map'，否则调试器读不到完整映射 - 启动调试前，手动访问
http://localhost:xxx/xxx.js.map确认能返回合法 JSON，404 就说明构建没生成或路径不对
C++/CMake 项目断点错位：Debug 模式 ≠ 调试可用
即使 CMAKE_BUILD_TYPE 设成了 Debug，只要编译器加了 -O1 及以上优化，GDB/LLDB 就会把变量内联、删掉空行、重排执行顺序——断点打在第 23 行，实际停在第 27 行是常态。
- 在
CMakeLists.txt中必须同时设置：set(CMAKE_BUILD_TYPE "Debug")+set(CMAKE_CXX_FLAGS_DEBUG "-g -O0") - 不要复用
CMAKE_CXX_FLAGS，它会被 Release 和 Debug 共享；用CMAKE_CXX_FLAGS_DEBUG和CMAKE_CXX_FLAGS_RELEASE分开控制 - 构建前清理缓存：
cmake --build . --clean-first，否则旧的优化目标文件可能残留 - 确认生成的可执行文件带调试符号：Linux 下运行
file ./build/myapp，输出含with debug_info才算成功
Node.js 调试时“连蹦带跳”：--inspect 启动方式决定步进精度
用 node app.js 直接运行再 attach，或没加 --inspect-brk，会导致 V8 调试器错过入口代码的符号加载时机——结果就是所有断点都“软绑定”，单步时跳过函数体、跳过 await、甚至跳过整个模块初始化。
- launch.json 的
type必须是pwa-node（新版 Node 调试器），不是过时的node - 确保
runtimeExecutable指向真实 Node 可执行文件路径，而非 shell 别名或 nvm wrapper - TS 项目务必加
"env": { "TS_NODE_TRANSPILE_ONLY": "true" }，否则ts-node可能绕过 source map - 禁用 Chrome DevTools 的缓存：DevTools → Network → ✅ Disable cache，否则可能加载旧版无 map 的 JS
真正卡住调试的，往往不是某一行代码写错了，而是构建产物和调试配置之间那层薄薄的映射关系断了。每次断点跳行，先查 source map 是否可访问、-O0 是否生效、--inspect-brk 是否前置——这三处任一缺失，都会让调试器在黑暗中摸索。
