在 Linux 上调试 Rust 程序，真正容易卡住的通常不是语法，而是工具链没配顺：调试器装了没、编译产物有没有调试符号、命令行和编辑器该走哪条路。下面按实际排查顺序整理一遍，从 GDB/LLDB 安装，到 VS Code 图形化调试，再到 dbg!、断言和日志这些补充手段，帮助你更快判断哪种方式最适合当前问题。
先把 Linux 上的调试器装好
在 Linux 上调试 Rust，第一步是准备好底层调试器。常见选择是 GDB 和 LLDB，Ubuntu 或 Debian 用户可以直接安装：
sudo apt install gdb
sudo apt install lldb如果你希望调试体验更贴近 Rust，本地还可以补上 Rust 官方工具链里的包装器：
rustup component add llvm-tools-preview安装后可以使用 rust-gdb 和 rust-lldb。这两个命令本质上是为 Rust 场景准备的包装器，能更好识别 Rust 的源码结构，通常比直接调用通用调试器省事一些。
编译时别把调试信息丢掉
调试器能不能看懂你的程序，前提是可执行文件里带有调试符号。对大多数 Rust 项目来说，直接执行下面这条命令就够了：
cargo build默认情况下，生成的可执行文件位于 target/debug/，其中已经包含调试所需的信息，一般不需要额外配置。
这里最需要注意的是不要误用 --release。发布模式会剥离调试信息，结果往往是调试器能启动，但变量、源码位置和调用细节都不完整，排查问题时会非常别扭。也就是说，如果你的目标是定位 bug，就优先使用调试构建，而不是发布构建。
命令行调试怎么进入和操作
命令行是最直接的方式，适合先确认程序在调试器里能不能正常跑起来。你可以直接调用 GDB 或 LLDB：
gdb target/debug/your_program
lldb target/debug/your_program不过更推荐的入口仍然是 Rust 包装器：
rust-gdb target/debug/your_program进入调试会话后，下面这些基础命令基本就能覆盖大部分排查场景：
- 设置断点：
break file.rs:line_number，例如break main.rs:10，程序执行到第 10 行会暂停。 - 运行程序：
run，简写是r。 - 单步执行：
next（n）按行向前走，但跳过函数内部；step（s）会进入函数体。 - 查看变量：
print variable_name，简写p，例如p x。 - 查看调用栈：
backtrace，简写bt，定位崩溃和错误路径时尤其常用。 - 继续执行：
continue，简写c，程序会继续跑到下一个断点或结束。
如果只是想快速定位“程序在哪一行开始不对劲”，常见顺序通常是：先下断点，再 run，命中后用 next/step 逐步看执行路径，必要时配合 print 和 backtrace 补上下文。
在 VS Code 里做图形化调试
如果你更习惯在编辑器里看断点、变量和调用栈，可以直接用 Visual Studio Code。基本流程并不复杂：
- 先安装 Rust Analyzer 扩展。
- 打开项目根目录，进入左侧“运行和调试”。
- 创建
launch.json。 - 选择 LLDB 或 GDB 作为调试环境。
自动生成的模板通常还需要改几项关键配置：程序路径、命令行参数（如果有）、工作目录，以及将 sourceLanguages 设置为 rust。这些信息配对以后，点击绿色箭头就能启动调试。
这套方式的优势在于，断点管理、变量监视、调用栈查看都能放到同一界面里完成，比较适合需要频繁切换源码、栈信息和运行状态的场景。对于刚从命令行调试切到 IDE 的 Rust 开发者来说，先保证 launch.json 指向的是 target/debug/ 下的程序，往往比额外折腾复杂配置更重要。
除了调试器，还能用哪些辅助工具
Rust 本身也提供了一些很实用的调试手段，适合和调试器配合使用，而不是完全替代调试器。
dbg!：最快的现场打印方式
dbg! 宏适合临时检查变量和表达式结果。例如：
dbg!(x)运行时会输出类似下面的内容：
[file.rs:2] x = 42它会把变量名、文件名和行号一起打出来，比普通打印更适合快速确认“值是什么、是在哪一行打印的”。当问题还没复杂到必须进调试器时，dbg! 往往是最快的一步。
assert! 和 debug_assert!：让条件错误尽早暴露
assert!(condition) 用于检查关键条件，条件为 false 时程序会直接终止，这种检查在生产环境也成立。
debug_assert! 更适合开发阶段验证内部逻辑。它在调试时很有用，但在 --release 模式下会被优化掉，因此适合那些“希望开发期严格检查、上线后不保留额外开销”的场景。
日志：用运行轨迹补齐上下文
当问题不是单点变量错误，而是执行流程不清楚时，日志通常比单纯打断点更高效。原文给出的组合是 log 作为日志门面，搭配 env_logger 作为日志实现。在代码里可以插入：
log::info!("Program started")运行前设置环境变量：
RUST_LOG=info cargo run这样就能看到 info、debug、error 等不同级别的输出。它特别适合排查跨函数、跨模块的问题，因为你可以先用日志把程序路径勾出来，再决定是否需要进一步进入 GDB 或 LLDB。
整体来看，Rust 在 Linux 上的调试并不缺工具，关键在于顺序要对：先确认调试器和调试符号，再决定用命令行还是 VS Code，最后用 dbg!、断言和日志补足现场信息。这样搭起来之后，多数常见问题都能比较快地收敛。
