断点变空心是因为调试器无法定位源码行，主因是缺少调试符号（如c++需-g、c#需portable pdb）、source map路径错位、node调试未正确启动或attach、vscode路径配置错误及缓存残留。
断点变空心，不是代码没运行，是调试器根本没“看见”你写的那行源码——它连该停在哪都不知道。
断点空心但提示“未绑定”，先查编译是否带调试符号
尤其是 C++、Rust、C# 或 .NET 项目：空心圆大概率因为二进制里压根没嵌入调试信息。GDB / LLDB / CLR 调试器靠 DWARF（Linux/macOS）、PDB（Windows）或 Portable PDB 定位源码行，没这些，就只能瞎猜。
- C++ 编译必须加
-g且禁用优化：g++ -g -O0 main.cpp -o main；-O2会内联、删变量、重排逻辑，断点位置直接失效 - C# 项目检查
.csproj是否含<debugtype>portable</debugtype>，并确认dotnet build输出目录下存在.pdb文件 - Rust 默认 debug 模式已含调试符号，但若用
cargo run --release启动，就会丢符号——必须用cargo run或显式加--debug
TypeScript/JS 项目断点不映射，重点看 source map 路径链
你打在 src/index.ts 上，VSCode 却要去 out/index.js 里找对应行——这中间全靠 sourceMap 文件串联。任一环节路径错位，断点就悬空。
-
tsconfig.json必须设"sourceMap": true，且"outDir"和"rootDir"明确（不能留空或用./） -
launch.json的outFiles字段要匹配 JS 输出路径，例如["${workspaceFolder}/dist/**/*.js"]；漏写或路径通配错误，VSCode 就加载不到 map - Webpack/Vite 用户额外检查构建配置：
devtool: 'source-map'（非eval-source-map），并确认.map文件真被输出到磁盘（不是只在内存里）
Node.js 调试启动方式不对，断点永远等不到进程
VSCode 的 Node 调试器不是“监听任意 Node 进程”，而是必须由它自己启动、或精确 attach 到带 --inspect 的进程。手动 node app.js 启动，断点必然无效。
- 用
launch模式时，确保program指向.js入口（不是.ts），且runtimeExecutable未误配成其他 Node 版本 - 用
attach模式时，启动命令必须含--inspect-brk=9229（-brk才能卡在第一行，方便设断点），且port在launch.json中严格一致 - 避免多 Node 进程干扰：比如同时开着
npm run dev和另一个node server.js，VSCode 可能 attach 错了进程
launch.json 配置看似正确，但路径是相对的陷阱
program、cwd、outFiles、resolveSourceMapLocations 全部用相对路径时，VSCode 解析依赖当前工作区根目录——而这个“根目录”未必是你想象的那个。
- 确认
.vscode/launch.json真的在你打开的工作区根目录下，不是嵌套子文件夹里误建的 -
program值推荐用变量："${workspaceFolder}/dist/app.js"，别写死成./dist/app.js（后者在某些插件或远程开发场景下会解析失败） - 前端项目若用 Webpack Dev Server，
webRoot必须指向实际服务的静态资源根，比如"${workspaceFolder}/public"，否则 sourcemap 路径拼接失败
最易被忽略的一点：断点空心有时不是配置问题，而是 VSCode 缓存了旧的调试会话状态。关掉所有窗口，删掉 .vscode/.debug（如有）和 node_modules/.cache，再重启——比调半小时 launch.json 更快见效。
