Rust 调试调查报告 2026

来源： Rust 博客
作者： Sam Kellam
发布时间： 2026/9/7 08:00:00
原文链接： https://blog.rust-lang.org/2026/09/07/rust-debugging-survey-2026-results/

---

Rust 开发者在我们的年度调查中报告的最大挑战之一是调试体验不佳。因此，在二月份，我们开展了首次 Rust 调试调查，希望了解 Rust 开发者如何使用调试器以及在使用过程中遇到的问题。我们收到了超过 2300 份回复，在此感谢每一位抽出时间参与调查的朋友！

在本报告中，我们将介绍调查的部分结果。如果你愿意，也可以查看完整的调查结果。

如果你想直接跳到某个特定部分，可以使用以下索引：

• 谁在使用调试器？
• 调试器是如何使用的？
• 挑战
• 调试器可视化工具
• 结语

谁在使用调试器？

理解调查结果的第一步是了解谁参与了调查。我们请受访者对自己的 Rust 熟练程度进行评分，从“从未使用过”到“高级”。超过 80% 的人自评为“高级”或“中级”，两者占比大致相当：

我们还询问受访者目前是否使用或曾经在 Rust 中使用过调试器。超过 46% 的人表示目前正在使用，其余回复则分为“过去使用过”和“从未使用过”。这意味着超过一半的受访者目前并未在 Rust 中使用调试器！

按熟练程度分类后，结果显示大约一半的“初学者”从未在 Rust 中使用过调试器！另一方面，近半数的“高级用户”目前确实在 Rust 中使用调试器：

对于那些表示曾经使用过 Rust 但现已不再使用的受访者，我们询问调试支持的挑战是否是放弃的原因。近 3% 的人回答“是”，另有 24% 的人表示调试问题属于部分原因（不过请注意回复数较少；大多数受访者都是 Rust 的活跃用户）：

调试器是如何使用的？

了解开发者在使用哪些调试器以及如何使用，是理解他们所面临挑战的另一个重要方面。为此，我们询问了受访者如何调试程序。不出所料，大多数开发者使用打印调试和 dbg! 宏。排除这些之外，在 IDE 中使用 lldb 是最受欢迎的选择，其次是在命令行中使用 gdb：

如果我们将受访者使用特定调试方法的操作系统纳入统计，就能得到更详细的结果分解。我们从两个不同角度来看待这个问题。第一个角度是：“在操作系统 X 上，使用调试器 Y 的回复占比是多少？”打印调试和 dbg! 宏再次稳居前两名，但在此基础上进一步观察，情况就更有意思了。在 Linux 上，命令行中使用 gdb 是最受欢迎的选择，仅以 0.4% 的微弱优势击败了在 IDE 中使用 lldb。在 Windows、适用于 Linux 的 Windows 子系统（WSL）和 macOS 上，在 IDE 中使用 lldb 都是首选，领先幅度至少为 6%，因此它总体上是一个非常受欢迎的选择。在 Windows 上，最不受欢迎的三个选择是命令行调试器（gdb 命令行、lldb 命令行和 BugStalker），而在 Windows 和 macOS 上，第三受欢迎的选择是“我不知道”。在未列出的操作系统（其他）上进行调试的受访者，最常使用某种特殊的嵌入式调试器或 gdb：

我们可以从另一个角度来看这些回复：“对于调试器 X 的用户，在操作系统 Y 上使用它的回复占比是多少？”对于大多数调试器，Linux 占据最大的使用份额，范围约为 45% 到 77%，其次是 Windows，再到 macOS。最显著的例外是 WinDbg 和 Visual Studio 调试器，它们主要用于 Windows；以及 lldb，它无论是在 IDE 中还是在命令行上，在 macOS 上的使用都多于 Windows：

对于在 Linux 上使用 WinDbg 的 6 位受访者：祝你们好运！

关于人们实际如何使用自己所选调试器的问题，总体结果并不特别令人意外。大约87%的用户使用调试器逐行单步执行程序，略超半数的用户使用调试器从挂起/崩溃的进程中获取堆栈跟踪。只有四分之一的受访者使用调试器调试异步（async）代码。这部分可能是因为 Rust 的异步调试体验尚不完善、功能残缺，也可能只是用户本身并没有编写大量异步代码：

如果按专业水平对这些结果进行细分，我们可以更多地了解使用模式。随着用户对 Rust 的经验越来越丰富，他们出于学习目的使用调试器的频率会降低，而从崩溃进程中获取堆栈跟踪的频率会升高：

关于 Rustaceans 如何使用调试器的最后一点洞察是：他们是否在调试同时使用 Rust 和其他编程语言的程序。对于44%的受访者来说，答案是“是”——这是一个相当高的比例！

至于涉及哪些语言，C 语言以略超70%的比例占据主导地位，其次是 C++（约43%）和 Python（约20%）：

挑战

我们没有直接提出“你在使用调试器时遇到什么问题？”之类的问题，而是首先询问受访者：每当他们决定不使用调试器时，原因是什么——包括那些不一定属于“调试器问题”的原因。

最常见的回答是：使用日志或打印调试来解决问题更容易或更快，略超81%的受访者报告了这一原因。这部分可以用开放式回答来解释——其中包含对调试器难以设置和/或使用的抱怨（尤其是在 Windows 上、处理 Web Assembly 时或嵌入式环境中），以及一些观点认为小而简单的问题根本不需要调试器。这不禁让人思考：用户体验是否能够做得足够便捷，从而取代打印调试的地位？但似乎很难击败一种如此直观的方法。其次是约37%的受访者表示，他们编写的代码“开箱即用”（Just Works）。这也说得通。再之后，约26%的受访者表示，在处理某些语言特性支持不佳的情况下，他们选择不使用调试器。这一比例略高于标准库类型的问题（约22%），而标准库类型的问题又略高于外部库类型的问题（约20%）：

由于逐行单步执行代码被预期为调试器最常见的用途之一，我们直接询问了受访者在单步执行时是否遇到任何问题。略超51%的受访者表示确实遇到了问题！对于这些报告在单步执行代码时遇到问题的受访者，我们进一步询问了他们在什么情况下遇到问题。异步（async）代码是最常见的情况，略超28%；其次是涉及宏（macro）的代码，约为23%。最不常见的情况是涉及函数指针（function pointer）的代码，接近6%：

我们还直接询问受访者：标准库中有哪些类型难以处理（如果有的话）。这是一个开放式问题，通读所有回答后，一些特别常见的抱怨集中在enum和集合类型上，尤其是std::collections::HashMap和std::vec::Vec。这一点也可以在完整报告中的词云里看到。

我们请受访者指出在使用 Rust 调试器时遇到过哪些痛点（如果有的话）。略超74%的比例中，值表示不佳（poor representation of values）以明显优势成为最常见的痛点，其次是无法打印变量（just over 55%）：

调试器可视化器

我们询问受访者是否为库作者（library author），如果是，是否了解并使用debugger_visualizer属性。近62%的受访者表示，他们是库作者，但不知道这个属性：

对于表示自己是库作者、知道该属性但未使用它的受访者，我们还进一步询问了原因。这部分受访者占比要小得多，请记住这一点！话虽如此，这些库作者中有一半表示他们没有时间维护可视化器属性，略低于一半的人表示他们不知道如何编写可视化器脚本。

对于一直阅读本节并疑惑 debugger_visualizer 属性是什么的读者，可以在 The Rust Reference: Debugger Attributes 中查阅相关资料。简而言之，debugger_visualizer 属性可以应用于模块或 crate 根，以在调试信息中嵌入文件，从而改善特定调试器对值的显示效果。目前支持的两种文件类型是：用于微软调试器（如 WinDbg）的 Natvis 文件，以及用于 GDB 的“pretty printers”（美化打印脚本），后者是 GDB 使用的结构化 Python 脚本。

结语

感谢大家参与本次调查，我们获得了一些关于 Rustaceans 如何使用调试器以及他们遇到哪些问题的深刻见解。例如，了解到如此高比例的用户正在遭受值显示效果不佳的问题，同时结合以下信息：哪些标准库类型导致了这些问题、许多库作者从未听说过 debugger_visualizer 属性，以及许多听说过但未使用该属性的人要么不知道如何使用、要么没有时间维护可视化脚本。

展望未来，调查结果表明，有几种显著的方式可以大幅改善 Rust 中的调试体验，例如：

• 修复调试器对 enum（枚举）的表示方式，使其显示实际的变体
• 修复调试器对集合类型（如 HashMap）的表示方式，使其显示内容而非实现细节
• 修复调试器对字符串类型（如 String 和 CString）的表示方式，使其以文本形式呈现而非实现细节
• 改善 async 的调试体验，尤其是在堆栈跟踪方面
• 改善对某些状态机（如迭代器和 Future）的单步调试体验
• 提供一些常用调试器的基本设置和使用文档

一个可能解决前三点问题的常见建议是：在调试器中利用类型的 Debug 实现来显示值。这种方法存在一些挑战，例如 Debug 实现只有在程序某处实际用到时才会出现在最终二进制文件中，但这并非不可能实现。值得注意的是，BugStalker 调试器已经支持该功能（前提条件同样是 Debug 实现必须被实际使用），你们中有些人正是通过这次调查才第一次听说它的！该调试器似乎也对 async 提供了一定支持，并计划进一步扩展。

目前，调试体验正在改进的一个显著途径是 正在进行的 Google Summer of Code 项目，该项目旨在改进我们对调试信息和可视化脚本的测试方式，从而更轻松地维护和改进我们自己的可视化脚本，以及在无静默破坏或回归的情况下保持与可视化脚本的总体兼容性。

我们再次感谢所有抽出时间参与本次调查的人！