Rust 调试调查 2026 年结果

# Rust 调试调研 2026 年结果 | Rust 官方博客 来源：https://blog.rust-lang.org/2026/09/07/rust-debugging-survey-2026-results/ 在我们每年的调查中 (https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/#challenges-and-wishes-about-rust)，Rust 开发者报告的最大挑战之一就是调试体验不佳。因此，早在二月份，我们启动了首次 Rust 调试调研 (https://blog.rust-lang.org/2026/02/23/rust-debugging-survey-2026/)，旨在了解 Rust 开发者如何使用调试器，以及他们在使用过程中遇到了哪些问题。我们收到了超过 2,300 份回复，在此感谢所有抽出时间参与调研的朋友！ 本报告将概述此次调研的部分结果。如您感兴趣，也可以查看完整的调研结果报告 (https://raw.githubusercontent.com/rust-lang/surveys/main/surveys/2026/debugging/report/debugging-survey-2026-report.pdf)。 如果您希望直接跳转到特定章节，可使用以下索引： - 谁在使用调试器？ (https://blog.rust-lang.org/2026/09/07/rust-debugging-survey-2026-results/#who-uses-debuggers) - 调试器如何被使用？ (https://blog.rust-lang.org/2026/09/07/rust-debugging-survey-2026-results/#how-are-debuggers-used) - 面临的挑战 (https://blog.rust-lang.org/2026/09/07/rust-debugging-survey-2026-results/#challenges) - 调试器可视化工具 (https://blog.rust-lang.org/2026/09/07/rust-debugging-survey-2026-results/#debugger-visualizers) - 总结 (https://blog.rust-lang.org/2026/09/07/rust-debugging-survey-2026-results/#closing-remarks) ## 谁在使用调试器？ 理解调研结果的第一步是了解参与调研的人员构成。我们请受访者评估自己的 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、Windows Subsystem for Linux (WSL) 和 macOS 上，IDE 中的 `lldb` 是首选，领先优势至少达 6%，因此它总体上是非常受欢迎的选择。在 Windows 上，最不受欢迎的三个选择是命令行调试器（`gdb` CLI、`lldb` CLI 和 BugStalker）；而在 Windows 和 macOS 上，第三受欢迎的选择是“我不知道”。那些在未列出的操作系统（“其他”）上进行调试的人，最常使用的是某种特殊的嵌入式调试器或 `gdb`： 我们看待这些回复的另一个角度是：“对于调试器 X 的用户，有多大比例的回复是在操作系统 Y 上使用它的？” 对于大多数调试器，Linux 占使用量的最大比例，范围从约 45% 到约 77%，其次是 Windows，然后是 macOS。最显著的例外是 WinDbg 和 Visual Studio 调试器（主要在 Windows 上使用），以及 `lldb`，无论是在 IDE 中还是命令行，它在 macOS 上的使用量都多于 Windows： 致那 6 位在 Linux 上使用 WinDbg 的受访者：祝你们好运！ 至于人们如何实际使用他们选择的调试器，总体结果并不特别出人意料。约 87% 的用户使用调试器逐行单步调试程序，略高于一半的用户使用调试器从挂起/崩溃的进程中获取堆栈跟踪。只有四分之一的受访者使用调试器调试异步代码。这可能部分是由于异步 Rust 的调试体验笨拙且不完善，也可能只是因为用户编写的异步代码不多： 如果按专业水平细分这些结果，我们可以更深入地了解使用模式。随着用户在 Rust 方面变得更有经验，他们使用调试器进行学习的情况减少，而从崩溃进程中获取堆栈跟踪的情况增多： 关于 Rust 开发者如何使用调试器的最后一个洞察是，他们调试的程序是否使用 Rust 与其他编程语言的混合。对于 44% 的受访者，答案是“是”，这是一个相当高的比例！ 至于这些语言是哪些，C 以略高于 70% 的比例占据主导地位，其次是 C++（约 43%）和 Python（约 20%）： ## 面临的挑战 我们没有直接问“在使用调试器时你面临哪些问题？”之类的问题，而是首先询问受访者在决定不使用调试器时的原因，包括那些不一定是“调试器问题”的原因。 最常见的报告原因是使用日志或打印调试更容易或更快地解决问题，有略高于 81% 的受访者这样报告。这可能部分源于开放性回复，其中抱怨调试器设置和/或使用过于困难（尤其是在 Windows 上、处理 WebAssembly 时或在嵌入式环境中），以及认为小问题和/或简单问题根本不需要调试器的观点。这不禁让人思考，用户体验能否变得足够便捷以至于取代打印调试，但似乎很难击败如此直观的方法。其次是约 37% 的受访者表示他们编写的代码就是能正常工作。好吧。之后，约 26% 的受访者表示，在涉及对语言特性支持不佳的情况下，他们决定不使用调试器。这略多于标准库类型的问题（约 22%），而后者又略多于外部库类型的问题（约 20%）： 由于单步调试代码被预期是调试器最常见的用途之一，我们直接询问受访者在此过程中是否遇到问题。略高于 51% 的受访者表示遇到了问题！对于那些报告单步调试代码遇到问题的受访者，我们询问他们何时遇到问题。异步代码是报告最多的常见情况，略高于 28%，其次是涉及宏的代码（约 23%）。报告最少的情况是涉及函数指针的代码（接近 6%）： 我们还直接询问受访者，标准库中哪些类型难以处理。这是一个开放式问题，回顾回复，一些特别常见的抱怨是关于 `enum` 和集合类型，特别是 `std::collections::HashMap` 和 `std::vec::Vec`。这在完整报告 (https://raw.githubusercontent.com/rust-lang/surveys/main/surveys/2026/debugging/report/debugging-survey-2026-report.pdf) 的词云中也可见。 我们请受访者指出，在使用调试器调试 Rust 时遇到了哪些痛点。略高于 74% 的受访者表示“值的表示形式不佳”是最常见的痛点，遥遥领先；其次是“无法打印变量”，略高于 55%： ## 调试器可视化工具 我们询问受访者是否为库作者，如果是，是否了解并使用 `debugger_visualizer` 属性。接近 62% 的受访者表示他们是库作者，但不了解此属性： 对于那些表示他们是库作者且知道该属性但未使用的受访者，我们也询问了原因。这部分受访者占比较小，请注意！话虽如此，其中一半的库作者表示他们没有时间维护可视化器属性，略低于一半的受访者表示他们不知道如何编写可视化器脚本： 对于那些阅读本节时自问 `debugger_visualizer` 属性是什么的读者，您可以在《Rust 参考手册：调试器属性》(https://doc.rust-lang.org/reference/attributes/debugger.html) 中了解它。简而言之，`debugger_visualizer` 属性可以应用于模块或 crate 根，以将文件嵌入调试信息中，从而改善某些调试器对值的显示。目前支持的两种文件类型是 Natvis 文件（被 Microsoft 调试器如 WinDbg 使用）和 GDB “美化打印程序”（GDB 使用的结构化 Python 脚本）。 感谢您参与此次调研，我们获得了关于 Rust 开发者如何使用调试器以及面临哪些问题的宝贵洞察。例如，得知如此高比例的用户遇到值的表示形式不佳的问题，结合了解哪些标准库类型导致问题；得知许多库作者从未听说过 `debugger_visualizer` 属性；以及得知许多知道但未使用该属性的库作者要么不知如何使用，要么没时间维护可视化器脚本。 展望未来，调研结果表明，有几个显著的方式可以极大改善 Rust 的调试体验，例如： - 修复调试器表示 `enum` 的方式，使其显示实际的变体 - 修复调试器表示集合（如 `HashMap`）的方式，使其显示内容而非实现细节 - 修复调试器表示字符串类型（如 `String` 和 `CString`）的方式，使其渲染为文本而非实现细节 - 改善异步调试体验，特别是堆栈跟踪方面 - 改进单步调试某些状态机（如迭代器和 `Future`）的体验 - 提供关于一些常用调试器基本设置和使用的文档 一个可能解决前三个问题的常见建议是使用类型的 `Debug` 实现在调试器中显示它们。这种方法存在挑战，例如 `Debug` 实现只有在程序中实际使用时才会包含在最终二进制文件中，但并非不可能。值得注意的是，`BugStalker` (https://github.com/godzie44/BugStalker) 调试器已经支持此功能（前提是 `Debug` 实现必须被实际使用），其中一些人是从本次调研中首次听说它的！它似乎对异步也有一定支持，并计划扩展。 目前改善调试体验的一个显著方式是通过进行中的 Google Summer of Code 项目 (https://summerofcode.withgoogle.com/programs/2026/projects/gzkF5BG0)，改进我们测试调试信息和可视化器脚本的方式，从而更容易维护和改进我们自己的可视化器脚本，并提高与可视化器脚本的通用兼容性，避免静默故障或回退。 再次感谢所有抽出时间参与调研的朋友！