Rust 官方在 2026 年 9 月 7 日公布了首份调试专项调查。调查收到 2,300 多份回复，结果显示，受访者里目前使用 Rust 调试器的比例只有略高于 46%；在真正使用调试器的人中，异步代码、宏和复杂类型的可读性仍然是明显短板。对 Rust 开发者来说，这份报告最有价值的地方不在于又多了一组社区统计，而在于它把“调试体验不好”拆成了可以验证、可以改进的工程问题。
先看调查告诉了我们什么
这份调查不是对所有 Rust 开发者的普查。超过 80% 的受访者自评为中级或高级用户，样本本身更接近活跃的 Rust 社区。因此，下面的数据适合用来识别工具链痛点，不适合直接推断整个 Rust 用户群体的比例。
| 观察 | 调查结果 |
|---|---|
| 当前使用 Rust 调试器 | 略高于 46% |
| 使用调试器进行逐行执行 | 约 87% |
| 使用调试器查看卡住或崩溃进程的堆栈 | 略高于一半 |
| 使用调试器调试异步代码 | 约四分之一 |
| 调试时遇到值表示不佳 | 略高于 74% |
| 调试时无法打印变量 | 略高于 55% |
还有一个很有意思的交叉结果：44% 的受访者会调试 Rust 与其他语言组合的程序，其中最常见的是 C，比例略高于 70%；其次是 C++，约 43%；Python 约 20%。这说明 Rust 的调试问题经常发生在 FFI、系统组件或已有工程的边界上，不能只把它当成单语言 IDE 功能来处理。
为什么大家仍然更喜欢日志和 dbg!
调查中，超过 81% 的受访者表示，在不使用调试器时，主要原因是日志或打印更简单、更快。这个结果并不等于调试器没有用。小问题用一行 println! 或 dbg! 解决，确实比配置调试会话更省事；真正的问题出现在故障需要暂停现场、观察多个变量、追踪异步状态，或者跨越 Rust 与 C/C++ 边界的时候。
调试器要赢得这些场景，首先得降低启动成本。开发者需要知道如何生成带调试信息的构建、如何让 IDE 找到正确的 GDB 或 LLDB、如何处理容器和交叉编译产生的路径差异，以及如何在优化级别和可观察性之间取舍。如果这条链路太长，打印自然会成为默认选项。
对团队而言，一个实用的做法是把调试配置当成项目的一部分，而不是每个人本地的隐性知识。可以在仓库里固定开发构建 profile，提供 VS Code、Visual Studio 或命令行的启动配置，并用一个最小示例验证断点、堆栈和变量查看都能工作。新人第一次进入项目时，应该能在几分钟内启动一个可调试的程序。
真正难的是异步代码和复杂值
在遇到逐行执行问题的受访者中，异步代码是最常见的场景，比例略高于 28%；宏相关代码约 23%。异步代码的执行路径会在 await 处挂起和恢复，调试器看到的调用栈未必对应开发者脑中那条业务路径。宏则会把源码位置、展开后的代码和生成的调试信息叠在一起，单步执行时很容易出现“跳到不认识的地方”。
这两个问题的共同点是，调试器展示的是机器和编译器留下的执行信息，而开发者需要的是源代码层面的因果关系。改善它们不能只靠增加断点按钮，还需要更准确的调试信息、稳定的源码映射，以及 IDE 对异步任务和宏展开的专门呈现。
因此，排查 Rust 异步故障时，可以先把问题缩小为三个可观察对象：任务在哪里创建，在哪个 await 前后改变状态，最终由哪个线程或运行时唤醒。为关键状态增加结构化日志和请求标识，仍然很有必要；调试器适合补上“暂停后观察现场”这一环，而不是替代所有运行时观测。
值看不懂，调试器就很难留下来
调查中略高于 74% 的受访者遇到过值表示不佳的问题，略高于 55% 的受访者遇到过变量无法打印。报告还提到，enum、std::collections::HashMap 和 Vec 是经常被抱怨的标准库类型。
这类问题会直接改变开发者的调试习惯。断点本身可能已经命中，但如果变量窗口只能显示指针、内部布局或一大串难以阅读的字段，开发者还是会退回日志。对业务类型来说，情况更明显：一个包含缓存、状态机或智能指针的结构体，默认展示通常无法表达它在业务上的含义。
Rust 提供了 debugger_visualizer 属性，用来把 Natvis 文件或 GDB pretty printer 嵌入调试信息。最小示例可以写成：
1 |
Natvis 主要面向 Windows 调试器，例如 Visual Studio 和 WinDbg；GDB pretty printer 则是结构化的 Python 脚本。Rust Reference 规定，这个属性可以放在模块或 crate 根上，也可以重复使用来加载多个可视化文件。
不过，调查发现，接近 62% 的受访者既是库作者，又不知道这个属性。知道它但没有使用的库作者中，约一半表示没有时间维护可视化属性，接近一半表示不知道如何编写可视化脚本。这里存在一个很现实的维护问题：可视化文件和类型实现一样，都是库的调试接口，类型布局变化后也需要同步检查。
给库作者和团队的三个实践建议
1. 把调试体验纳入验收条件
新类型加入公共 API 时，除了检查编译、测试和文档，还可以问一句：开发者在断点处能看懂它吗？对集合、句柄、状态机和 FFI 包装类型，应该提供一个最小调试示例，确认 GDB、LLDB 或目标 IDE 至少有一种可读的展示方式。
2. 用真实故障测试调试配置
不要只验证程序能启动。可以准备一个包含异步任务、宏调用和跨语言边界的调试样例，定期在 CI 或开发环境中验证断点、堆栈、源码映射和变量打印。工具链升级后，先跑这个样例，比等到线上故障时才发现调试器失效更划算。
3. 让日志、追踪和调试器互相补位
日志适合回答“系统在长时间运行中发生了什么”，追踪适合回答“一个请求经过了哪些组件”，调试器适合回答“程序暂停在这里时，内存和控制流到底是什么状态”。三者解决的问题不同。把请求 ID、任务 ID 和关键状态统一起来，开发者才能从线上线索回到本地现场，而不是在三套工具之间重新猜测。
结语
Rust 这份调试调查给出的信号很具体：很多开发者不是不需要调试器，而是调试器还没有在复杂值、异步任务、宏展开和跨语言工程中提供足够清晰的反馈。短期内，团队可以先从可复现的开发配置、带调试信息的构建和关键类型的可视化做起；长期来看，编译器、调试信息格式、IDE 和库作者需要一起把“能停下来”推进到“停下来之后看得懂”。