Atom 不支持直接断点调试 C++，需手动启动 GDB 并配合 -g 编译；其 UI 断点仅为标记，不触发调试；GDB 中 break 命令才生效，且依赖符号信息完整、禁用优化及正确路径/函数名。
Atom 本身不支持直接加断点调试 C++，必须靠外部工具链配合 GDB 才能实现真正意义上的代码跟踪和断点停靠。 它没有内置调试器，所谓“加断点”只是视觉标记，不触发任何调试行为——这点和 VS Code 或 CLion 完全不同。
Atom 里点行号加的 breakpoint 根本不生效
你在 Atom 行号左侧点击出现的红点，只是 atom-debug 或 gdb-launcher 类插件做的 UI 标记，它不会自动传给 GDB。如果你没手动启动 GDB、没用 break 命令设断点，程序跑起来根本不会停。
- 常见错误现象：点了断点 → 按 F5 → 程序一闪而过，控制台输出完就退出，GDB 进程都没起来
- 根本原因：Atom 缺少调试协议（DAP）支持，无法和 GDB 建立会话级通信
- 正确做法：必须先用终端手动启动 GDB，或通过
platformio-ide-terminal插件开终端再执行gdb ./a.out - 编译时务必带
-g，否则 GDB 加了断点也找不到源码行映射，list命令会报 “No symbol table is loaded”
gdb 里设断点的几种可靠写法
在 GDB 交互界面中，break 命令才是真断点。注意路径、函数名、行号三者必须严格匹配当前加载的符号信息。
-
break main：进主函数就停（适合快速定位入口） -
break test.cpp:42：文件名必须和g++ -g编译时用的完全一致（区分大小写，含相对路径） -
break Vector::push_back：类成员函数要带作用域，否则 GDB 可能找不到重载版本 -
rbreak ^handle_.*：正则匹配所有以handle_开头的函数（适合批量下断，但性能略低） - 别用
break 42：这种行号是当前文件的绝对行号，切换文件后容易误设
条件断点必须满足三个硬性前提
想让 break test.cpp:100 if i == 5 生效，不是语法对就行——编译器优化和调试信息完整性会直接决定它是否被忽略。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 编译命令必须是
g++ -g -O0（禁用优化），-O1及以上可能导致i被提升为寄存器变量，GDB 查不到它的内存地址 - 条件表达式里的变量必须在当前栈帧作用域内，比如循环体外定义的
std::vector<int> v</int>，在循环内用v.size()通常可用，但v.at(0)很可能报Cannot evaluate function - STL 容器字段名随 libstdc++ 版本变化，
vec._M_impl._M_finish在 GCC 12 和 GCC 13 中字段名可能不同，建议先用ptype std::vector<int></int>确认实际结构 - 别在条件里调函数：如
if strlen(s) > 10，GDB 不保证函数可安全求值，可能崩溃或静默失败
多线程下 watch 和 break 混用要特别小心
Watchpoint（watch var）本质是硬件断点，和软件断点（break）机制不同，在多线程环境容易误触发或降级失效。
-
watch不支持if条件，watch x if x > 100这种写法会被 GDB 忽略，且不报错 - 想监控变量变化 + 加条件，得拆成两步：先
watch x，停住后用if x > 100判断，再continue - 多个线程同时改同一个变量时，
watch可能随机停在任意一个修改线程上，不如条件断点可控 - 频繁写的变量（如循环计数器）慎用
watch，硬件断点资源有限，容易耗尽导致后续断点失效
真正麻烦的从来不是怎么输命令，而是每次换机器、升级 GCC 或切换项目时，info locals 返回的变量列表是否完整、ptype 显示的 STL 字段是否和你文档里查的一致——这些细节不验证，条件断点大概率白设。
