Rust 调试调查 2026 结果：2300+ 开发者说了什么
Rust 年度调查里被报告最多的痛点之一是调试体验不佳。今年 2 月 compiler team 发起了首次 Rust Debugging Survey，收到 2300+ 份回复，9 月 7 日公布结果。核心发现：超过一半受访者当前不用调试器；用的人主力仍是 print 调试；值显示差是最常见痛点；近六成库作者不知道 debugger_visualizer 属性。
谁在用调试器
- 受访者超 80% 自评 "Advanced" 或 "Intermediate"，大致对半；
- 46% 当前使用调试器，其余为"以前用过"或"从未用过"——过半 Rust 开发者现在不用调试器；
- 按熟练度分：约半数初学者从未用过调试器；近半高级用户在用；
- 停止使用 Rust 调试器的受访者中，近 3% 归因于调试支持问题，另有 24% 认为部分相关（注意该组样本量小）。
怎么用
- print 调试与
dbg!宏稳居前二；排除后，IDE 内 lldb 最流行，其次命令行 gdb； - 分系统看：Linux 上命令行 gdb 以 0.4% 微弱优势超过 IDE 内 lldb；Windows/WSL/macOS 上 IDE 内 lldb 至少领先 6%；Windows 上最不流行的是三个命令行调试器（gdb CLI、lldb CLI、BugStalker）；Windows 和 macOS 上第三大选择是"我不知道"；
- 87% 的用户用调试器逐行单步；刚过半用它拿崩溃/挂起进程的堆栈；只有四分之一调试 async 代码；
- 44% 在调试 Rust 与其他语言混合的程序——C 占 70%+、C++ 约 43%、Python 约 20%。
挑战
- 不用调试器的第一大原因（81%）：日志或 print 调试更快更容易；开放回答里抱怨集中在难配置难上手（尤其 Windows、WebAssembly、嵌入式场景），以及小问题不值得上调试器；
- 51% 的人逐行单步时遇到过问题：async 代码最高（28%+），其次宏相关代码（23%），函数指针最少（近 6%）；
- 标准库难处理的类型：
enum与集合（尤其HashMap、Vec）； - 最普遍的痛点：值显示差（74%+），其次无法打印变量（55%+）。
Debugger Visualizers
- 近 62% 的库作者不知道
debugger_visualizer属性； - 知道的没用它的：一半没时间维护、近一半不知道怎么写 visualizer 脚本；
- 该属性可加在模块或 crate root，把文件嵌进调试信息改善调试器中的值显示，目前支持两种：微软调试器（WinDbg 等）的 Natvis 文件，和 GDB 的 pretty printer（结构化 Python 脚本）。
官方改进方向
调查指向几条显著路径：修复 enum 的显示（显示真实 variant）；集合类（HashMap）显示内容而非实现细节；字符串类型（String、CString）按文本而非内部结构渲染；改善 async 调试（尤其堆栈）；改善 iterator/Future 等状态机的单步；为常见调试器写基础配置与使用文档。一个常见建议是用类型的 Debug 实现来显示——但它有自己的挑战（如自定义 Debug 与调试器内建的取舍）。
实践建议
- 库作者：给你的类型加
debugger_visualizer属性（Natvis/GDB pretty printer），这是低成本高收益的用户体验投资； - 用调试器之前先检查环境配置成本——调查显示它挡住了一大批潜在用户；
- async 与宏展开的调试是已知弱项，遇到别硬扛，配合 print 与堆栈分析更高效。