Sublime Text 不支持图形化断点调试，其所谓“调试”实为通过终端手动调用 GDB/LLDB 的命令行操作，缺乏断点高亮、变量监视、调用栈等 GUI 功能，本质是伪调试。
Sublime Text 本身不支持图形化断点调试，所谓“配合 GDB/LLDB”实际只能做到：在终端里手动调用调试器，或通过插件间接触发命令行调试流程。真想点一下就停在断点、看变量、单步执行？它做不到——别被“Debugger”插件名误导。
为什么 Sublime Text 的 GDB 调试本质上是“伪调试”
Sublime Text 没有原生调试协议（如 VSCode 的 Debug Adapter Protocol），所有所谓“调试”都依赖外部进程启动和输出捕获。你看到的“GDB_C”构建变体，本质只是：gcc -g 编译 + start cmd /c gdb ... 启动一个新终端窗口，然后你自己敲 break main、run、print x……
这意味着：
- 断点不会在编辑器里高亮或自动命中，全靠你手输
break命令 - 没有变量监视窗、调用栈面板、寄存器视图这些 GUI 调试要素
- 如果程序需要交互输入（比如
scanf），终端窗口可能被 Sublime 锁住或无法响应 - 多线程、信号、fork 子进程等场景下，GDB 输出容易乱序，Sublime 不做解析也不做同步
Sublime Text + Terminus + Debugger 插件能做什么（M1/macOS/Linux 限定）
在 macOS（尤其是 M1/M2）或 Linux 上，Debugger 插件搭配 Terminus 可以绕过 GDB 权限问题，改用 LLDB 启动调试会话——但它仍不是图形化调试器，而是把 LLDB 的 CLI 界面嵌入到 Sublime 的面板里。
立即学习“C++免费学习笔记（深入）”；
关键实操点：
- 必须先装
Terminus：它提供可交互的终端面板，Debugger依赖它来运行调试器 -
Debugger的lldb配置项里，program必须指向已编译且带-g的二进制文件，路径不能含空格或中文 - 启动后，你会看到一个类似 GDB 的命令行界面，但所有操作仍需手动输入：比如
break main、run、next、print argc - LLDB 的
expr和frame variable比 GDB 更友好，尤其对 STL 容器；但你要知道怎么输，Sublime 不帮你补全 - Windows 下基本不可用：LLDB 在 Windows 的支持弱，
Debugger插件对gdb.exe的适配极差，经常卡在 “waiting for debugger to connect”
真正能跑通的最小可行配置（仅限 Linux/macOS）
如果你坚持用 Sublime Text 做轻量调试，只推荐这一条路径，跳过所有花哨插件：
- 确认系统已有
gdb或lldb：终端里运行gdb --version或lldb --version，必须返回版本号 - 编译时务必加
-g：比如gcc -g -o hello hello.c，否则调试器看不到符号信息 - 创建构建系统
GDB_Terminal.sublime-build：
{
"shell_cmd": "gcc -g \"${file}\" -o \"${file_path}/${file_base_name}\" && gnome-terminal -- bash -c 'gdb \"${file_path}/${file_base_name}\"; exec bash'",
"file_regex": "^(..[^:]*):([0-9]+):?([0-9]+)?:? (.*)$",
"working_dir": "${file_path}",
"selector": "source.c, source.cpp"
}说明：
-
gnome-terminal是 Linux 示例，macOS 改用open -a Terminal，Windows 则几乎无解（cmd /c start无法可靠传参） -
exec bash防止终端退出，方便你反复调试同一程序 - 不要指望 Sublime 自动跳转到源码行：GDB 报错行号能匹配
file_regex，但断点命中后不会反向高亮编辑器里的代码
真正复杂的地方从来不是配置文件怎么写，而是你得清楚：Sublime Text 的“调试”永远停留在命令行层面。它省不掉你对 gdb 或 lldb 命令本身的掌握——watch、info registers、set follow-fork-mode child 这些，没人替你输。工具越轻，人越得重。
