Rust 调试调查 2026 结果
中文
复制
2026年9月7日 · Sam Kellam 代表编译器团队
在年度调查中，Rust 开发者反映的最大挑战之一就是调试体验不佳。于是，今年二月我们开展了首次 Rust 调试调查，希望弄清 Rust 开发者如何使用调试器，以及在使用过程中遇到了哪些问题。我们收到了 2300 多份回复，感谢每一位抽出时间参与调查的人！在本报告中，我们将介绍部分调查结果。如果你愿意，也可以查看完整调查结果。如果想直接跳到某一节，可以用下面的索引：
谁在使用调试器？
要理解调查结果，第一步是了解参与调查的是哪些人。我们请受访者评估自己的 Rust 水平，从“从未用过”到“高级”。超过 80% 的人自评为“高级”或“中级”，两者大致各占一半：
我们还询问受访者目前是否在使用或曾经使用过 Rust 调试器。超过 46% 的人表示目前在用，其余回复则分布在“曾经用过”和“从未用过”之间。也就是说，超过一半的受访者目前并不使用 Rust 调试器！
按水平分类后，回复显示大约一半的“初学者”从未在 Rust 中使用过调试器！另一方面，近一半的“高级用户”目前在使用 Rust 调试器：
对于表示曾经用过 Rust 但后来不再使用的受访者，我们询问调试支持方面的困难是否是他们放弃的原因。近 3% 的人回答“是”，另有 24% 的人表示调试问题部分导致了他们放弃（不过要注意回复量很小；大多数受访者是 Rust 的活跃用户）：
调试器是怎么用的？
要了解开发者面临哪些困难，就得先知道他们在用什么调试器、怎么用。为此，我们询问了受访者平时如何调试程序。不出所料，大多数人用的是 print 调试和 dbg! 宏。除此之外，在 IDE 里使用 lldb 是最主流的选择，其次是命令行上的 gdb：
如果把受访者使用的操作系统也纳入统计，就能得到更细的拆分。我们从两个角度来看。第一个角度是：“在操作系统 X 上，使用调试器 Y 的回复占多大比例？”print 调试和 dbg! 宏依然稳居前二，但再往下看就更有意思了。在 Linux 上，命令行使用 gdb 以微弱优势位居第一，仅比 IDE 中的 lldb 高出 0.4%。在 Windows、Windows Subsystem for Linux（WSL）和 macOS 上，IDE 中的 lldb 至少领先 6 个百分点，是相当普遍的选择。在 Windows 上，最不受欢迎的三个选项都是命令行调试器（gdb CLI、lldb CLI 和 BugStalker）；而在 Windows 和 macOS 上，第三受欢迎的选项都是“我不知道”。在未列出的操作系统（Other）上调试的人，最常用的是某种专用嵌入式调试器或 gdb：
另一个角度是：“对于调试器 X 的用户，在操作系统 Y 上使用它的回复占多大比例？”对大多数调试器来说，Linux 占的使用量最大，大约在 45% 到 77% 之间，其次是 Windows，然后是 macOS。最明显的例外是 WinDbg 和 Visual Studio 调试器，它们主要在 Windows 上使用；还有 lldb，它在 macOS 上的使用量高于 Windows，无论是在 IDE 中还是命令行上：
致那 6 位在 Linux 上用 WinDbg 的受访者：祝你们好运！ 至于人们实际如何使用自己选用的调试器，汇总结果并不特别出人意料。大约 87% 的用户用调试器逐行跟踪程序，略多于一半的用户用调试器获取挂起或崩溃进程的堆栈跟踪。只有四分之一的受访者用调试器调试异步代码。这或许部分是因为异步 Rust 的调试体验既笨拙又不完整，也可能只是因为用户写的异步代码本来就不多：
如果按经验水平拆分这些结果，还能看出更多使用模式。随着用户对 Rust 越来越熟练，他们出于学习目的使用调试器的比例下降，而从崩溃进程中获取堆栈跟踪的比例上升：
关于 Rustacean 如何使用调试器的最后一点洞察，是他们是否在调试 Rust 与其他编程语言混用的程序。44% 的受访者回答“是”，这个数字相当高！ 至于具体是哪些语言，C 以略高于 70% 占据主导，其次是 C++ 约 43%，Python 约 20%：
挑战
我们没有一上来就问“你在使用调试器时遇到哪些问题？”，而是先问受访者，他们在哪些情况下会决定不用调试器，其中也包括一些未必算是“调试器本身有问题”的原因。
最常见的理由是：用日志或 print 调试来解决问题更简单、更快，略高于 81% 的受访者选择了这一项。开放题的回答或许能部分解释这一点：有人抱怨调试器太难配置、太难用（尤其是在 Windows 上、处理 Web Assembly 时，或是在嵌入式环境中），也有人认为小而简单的问题根本用不着调试器。这不禁让人想，用户体验要做到多方便，才能把 print 调试拉下马？但这么直观的东西，恐怕很难被超越。紧随其后的是大约 37% 的受访者，他们写的代码就是能跑。行吧。再往后，约 26% 的受访者表示，当所用语言特性支持不佳时，他们会选择不用调试器。这一比例略高于标准库类型相关的问题（约 22%），而后者又略高于外部库类型相关的问题（约 20%）：
既然单步执行代码被认为是调试器最常见的用途之一，我们直接问了受访者在单步执行时是否遇到过问题。略高于 51% 的人说遇到过！对于这些报告遇到单步执行问题的受访者，我们又问了他们是在什么情况下遇到的。最常见的是异步代码，略高于 28%；其次是涉及宏的代码，约 23%。最少见的是涉及函数指针的代码，接近 6%：
我们还直接询问了受访者，标准库中哪些类型（如果有的话）难以使用。这是一道开放性问题，通读回答后发现，比较常见的抱怨集中在 enum 和集合类型上，尤其是 std::collections::HashMap 和 std::vec::Vec。这一点在完整报告的词云中也能看出来。
我们请受访者指出，在使用 Rust 调试器时遇到过哪些痛点（如果有的话）。占比略高于 74% 的“值的展示效果差”是最常见的痛点，且明显领先，其次是占比略高于 55% 的“无法打印变量”：
调试器可视化工具
我们询问受访者是否为库作者，如果是，是否知道并使用了 debugger_visualizer 属性。近 62% 的受访者表示自己是库作者，但并不知道这个属性：
对于表示自己是库作者、知道这个属性但并未使用的人，我们还问了原因。这部分受访者占比要小得多，请注意这一点！即便如此，其中有一半表示自己没有时间维护可视化工具属性，略低于一半表示不知道如何编写可视化脚本：
如果你一路读到这里，心里还在琢磨 debugger_visualizer 属性到底是什么，可以去看 The Rust Reference: Debugger Attributes。简单来说，debugger_visualizer 属性可以用在模块或 crate 根上，把文件嵌入调试信息，让某些调试器更好地显示值。目前支持两种文件类型：Natvis 文件，供 WinDbg 等微软调试器使用；以及 GDB 的 "pretty printers"，即 GDB 使用的结构化 Python 脚本。
结语
感谢大家参与这次调查，我们得以深入了解 Rustacean 如何使用调试器、又面临哪些问题。比如，我们知道有大量用户苦于值的显示效果不佳，同时也知道是哪些标准库类型在制造麻烦；知道很多库作者没听说过 debugger_visualizer 属性；也知道在听说过的人里，不用它的要么不知道怎么用，要么没时间维护可视化脚本。
展望未来，调查结果指出了几个最能显著改善 Rust 调试体验的方向，例如：
- 修正调试器对
enum的显示方式，让它展示实际的变体 - 修正调试器对集合类型（如
HashMap）的显示方式，让它展示内容，而不是实现细节 - 修正调试器对字符串类型（如
String和CString）的显示方式，让它渲染成文本，而不是实现细节 - 改善
async的调试体验，尤其是栈回溯 - 改善某些状态机（如迭代器和
Future）的单步调试 - 提供一些常见调试器的基本配置与使用文档
要解决前三点，一个常见的建议是使用 Debug 类型实现，并在调试器中把它们显示出来。这种做法有它的难处，比如 Debug 实现只有在程序里真正被用到时才会出现在最终二进制文件中，但并非做不到。值得一提的是，BugStalker 调试器已经支持这一点（前提同样是 Debug 实现确实被用到），你们中有些人第一次听说它就是在这次调查里！它似乎还对 async 有一定支持，并计划继续扩展。
目前改善调试体验的一个显著途径是正在进行的 Google Summer of Code 项目，它改进了我们测试调试信息和可视化脚本的方式，让我们更容易维护和改进自己的可视化脚本，也更容易保持对可视化脚本的总体兼容性，而不会出现悄无声息的破坏或回归。
再次感谢所有抽出时间参与调查的人！