概览

本文分享 2022 年 6 月份 Go 开发者调查的结果。Go 团队在此感谢 5,752 位受访者分享了他们在使用 Go 1.18 中引入的新功能（包括泛型、安全工具和工作区）的体验。你们帮助我们更好地了解开发者如何发现和使用这些功能，正如本文将要讨论的，也为进一步改进提供了有价值的见解。谢谢！💙

主要发现

• 泛型得到快速采纳。绝大多数受访者都知晓 Go 1.18 版本已包含泛型，约四分之一的受访者表示已开始在 Go 代码中使用泛型。关于泛型最常见的单一反馈是“谢谢！”，但很明显，开发者已经遇到了一些初始泛型实现上的局限性。
• 模糊测试对大多数 Go 开发者而言是新事物。与泛型相比，内置的模糊测试的知晓度要低得多，受访者对何时或为何考虑使用模糊测试存在更多不确定性。
• 第三方依赖是首要安全顾虑。避免存在已知漏洞的依赖是受访者最关心的安全相关挑战。更广泛地说，安全工作通常是计划外且不被奖励的，这暗示着工具需要尊重开发者的时间和注意力。
• 我们可以更好地宣布新功能。随机抽样的参与者对近期 Go 工具发布的了解程度低于通过 Go 博客找到此调查的人。这表明我们应该超越博客文章来传达 Go 生态系统的变化，或扩大这些文章的传播范围。
• 错误处理仍然是挑战。继泛型发布后，受访者在使用 Go 时面临的首要挑战转向了错误处理。总的来说，对 Go 的满意度仍然很高，我们没有发现受访者使用 Go 的方式有任何显著变化。

如何解读这些结果

在本文中，我们使用调查回复的图表来支持我们的发现。所有这些图表都采用类似的格式。标题是调查受访者看到的实际问题。除非另有说明，问题是单选题，参与者只能选择一个答案；每个图表的副标题会告知您该问题是否允许选择多个答案，或者是一个开放式文本框而不是选择题。对于开放式文本回复的图表，Go 团队成员阅读并手动分类了所有回复。许多开放式问题引出了各种各样的回答；为使图表大小合理，我们将它们精简为最多前 10 个主题，其余主题都归类在“其他”项下。

为了帮助读者理解每项发现背后的证据力度，我们包含了误差条，显示了回复的 95% 置信区间；误差条越窄，置信度越高。有时两个或多个回复的误差条会重叠，这意味着这些回复的相对顺序在统计学上没有意义（即，这些回复实际上是并列的）。每个图表的右下角显示了包含在图表中的回复人数，格式为“n = [受访者人数]”。

方法论说明

大多数调查受访者是“自愿”参加调查的，意味着他们是在 Go 博客、Twitter 上的 @golang 或其他 Go 社交渠道上找到的。这种方法潜在的问题是，不关注这些渠道的人可能不太会了解到此调查，并且他们的回答可能与那些密切关注这些渠道的人不同。约三分之一的受访者是随机抽样的，意味着他们在 VS Code 中看到提示后回应了调查（在 2022 年 6 月 1 日至 6 月 21 日之间使用 VS Code Go 插件的每个人都有 10% 的几率收到此随机提示）。这个随机抽样组帮助我们将这些发现推广到更广泛的 Go 开发者社区。大多数调查问题在这些组之间没有显示出有意义的差异，但在少数有重要差异的情况下，读者将看到将回复细分为“随机样本”和“自选”组的图表。

泛型

在 Go 1.18 发布并支持类型参数（更常被称为泛型）之后，我们想了解泛型的初始认知度和采纳情况，以及使用泛型的常见挑战或障碍。

绝大多数调查受访者（86%）已经知道泛型作为 Go 1.18 版本的一部分已发布。我们曾希望看到一个简单多数，所以这个知晓率远超我们的预期。我们还发现，约四分之一的受访者已开始在 Go 代码中使用泛型（26%），其中包括 14% 表示已在生产环境或已发布的代码中使用泛型。大多数受访者（54%）不反对使用泛型，但目前没有此需求。我们还发现，8% 的受访者希望在 Go 中使用泛型，但目前被某事阻碍了。

是什么阻碍了一些开发者使用泛型？大多数受访者属于以下两类之一。首先，30% 的受访者表示遇到了当前泛型实现的一个限制，例如想要参数化方法、改进类型推断或对类型进行开关。受访者表示，这些问题限制了泛型的潜在用例，或者感觉它们使泛型代码不必要地冗长。第二类涉及依赖尚未支持泛型的内容——linter 是最常见的阻止采纳的工具，但此列表还包括组织仍在使用早期 Go 版本，或依赖尚未提供 Go 1.18 软件包的 Linux 发行版（26%）。12% 的受访者表示学习曲线陡峭或缺乏有用的文档。除了这些主要问题之外，受访者还告诉我们了各种不太常见（但仍然有意义）的挑战，如下面的图表所示。为了避免关注假设，本分析仅包括那些表示已在使用泛型，或尝试使用泛型但被某事阻碍的受访者。

我们还询问尝试使用泛型的受访者是否愿意分享任何其他反馈。令人鼓舞的是，十分之一的受访者表示泛型已经简化了他们的代码，或减少了代码重复。最常见的回复是“谢谢！”的变体或普遍的积极情绪（43%）；相比之下，只有 6% 的受访者表现出负面反应或情绪。与上述“最大挑战”问题的发现相呼应，近三分之一的受访者讨论了 Go 泛型实现的局限性。Go 团队正在利用这一系列结果来帮助决定是否以及如何放宽其中一些限制。

安全

继 2020 年 SolarWinds 泄露事件 之后，安全开发软件的做法受到了新的关注。Go 团队已将此领域的工作列为优先事项，包括用于创建 软件物料清单 (SBOM)、模糊测试，以及最近的 漏洞扫描。为支持这些工作，本次调查提出了一些关于软件开发安全实践和挑战的问题。我们特别想了解：

• Go 开发者目前使用哪些类型的安全工具？
• Go 开发者如何发现和解决漏洞？
• 编写安全 Go 软件面临的最大挑战是什么？

我们的结果表明，尽管静态分析工具得到了广泛使用（65% 的受访者），但只有少数受访者目前使用它来查找漏洞（35%）或以其他方式改进代码安全性（33%）。受访者表示，安全工具最常在 CI/CD 时间运行（84%），少数人表示开发者在本地开发过程中运行这些工具（22%）。这与我们团队进行的额外安全研究一致，该研究发现 CI/CD 时间的安全扫描是一种期望的后备措施，但开发者通常认为这对于首次通知来说太晚了：他们希望在构建依赖项之前就知道某个依赖项可能存在漏洞，或者在不等待 CI 运行针对其 PR 的完整额外测试集的情况下，验证版本更新是否解决了漏洞。

我们还询问了受访者在开发安全软件方面最大的挑战。最普遍的困难是评估第三方库的安全性（57% 的受访者），这是漏洞扫描器（如 GitHub 的 dependabot 或 Go 团队的 govulncheck）可以帮助解决的一个主题。其他主要挑战表明了额外安全工具的机会：受访者表示，在编写代码时很难始终如一地应用最佳实践，并且验证结果代码没有漏洞。

模糊测试是另一种提高应用程序安全性的方法，对大多数受访者来说仍然很新。只有 12% 的人表示在工作中使用它，5% 的人表示已采用 Go 的内置模糊测试工具。一项开放式后续问题询问了模糊测试难以使用的原因，发现主要原因并非技术问题：前三个回答讨论了不了解如何使用模糊测试（23%）、缺乏时间投入模糊测试或更广泛的安全（22%），以及不理解开发者为什么以及何时可能想使用模糊测试（14%）。这些发现表明，我们在沟通模糊测试的价值、应该模糊测试什么以及如何将其应用于各种代码库方面仍有工作要做。

为了更好地了解漏洞检测和解决过程中的常见任务，我们询问了受访者在过去一年中是否在其 Go 代码或其依赖项中发现了任何漏洞。对于那些发现漏洞的人，我们随后询问了最近期漏洞是如何发现的，他们如何调查和/或解决它，以及整个过程中最具挑战性的是什么。

首先，我们发现了漏洞扫描有效的证据。四分之一的受访者表示在其第三方依赖项中发现了漏洞。但请记住，只有约 ⅓ 的受访者在使用漏洞扫描——当我们查看那些表示运行某种漏洞扫描器的回复时，这个比例几乎翻倍，从 25% 增加到 46%。除了依赖项或 Go 本身中的漏洞外，12% 的受访者表示发现了自己代码中的漏洞。

大多数受访者表示通过安全扫描器发现漏洞（65%）。最常引用的单一工具是 GitHub 的 dependabot（38%），其引用频率高于所有其他漏洞扫描器总和（27%）。在扫描工具之后，发现漏洞的最常见方法是公开报告，如发行说明和 CVE（22%）。

一旦受访者了解到漏洞，最常见的解决方法是升级有漏洞的依赖项（67%）。在也讨论使用漏洞扫描器的受访者中（作为讨论第三方依赖项漏洞的参与者的代理），这一比例增加到 85%。不到三分之一的受访者讨论了阅读 CVE 或漏洞报告（31%），只有 12% 的人提到了更深入的调查以了解他们的软件是否（以及如何）受到漏洞的影响。

只有 12% 的受访者表示他们调查了漏洞是否可以在其代码中触及，或者它可能对服务产生的影响，这令人惊讶。为了更好地理解这一点，我们还查看了受访者认为在响应安全漏洞方面最具挑战性的是什么。他们以大致相等的比例描述了几个不同的主题，从确保依赖项更新不会中断任何内容，到理解如何通过 go.mod 文件更新间接依赖项。此列表中还包括理解漏洞影响或根本原因所需的调查类型。但是，当我们仅关注表示进行过这些调查的受访者时，我们会看到一个清晰的相关性：70% 表示调查过漏洞潜在影响的受访者认为这是此过程中最具挑战性的部分。原因不仅在于任务的难度，还在于这项工作通常是计划外且不被奖励的。

Go 团队认为，这些需要理解应用程序如何使用有漏洞的依赖项的深入调查，对于理解漏洞可能给组织带来的风险，以及了解是否发生了数据泄露或其他安全事故至关重要。因此，我们设计了 govulncheck，使其仅在漏洞被调用时才提醒开发者，并指向他们代码中正在使用有漏洞函数的具体位置。我们希望这能使开发者更容易快速调查真正重要的漏洞，从而减少该领域的计划外工作总量。

工具

接下来，我们调查了三个关于工具的问题：

• 自上次调查以来，编辑器格局是否发生了变化？
• 开发者是否在使用工作区？如果使用，在入门过程中遇到了哪些挑战？
• 开发者如何处理内部软件包的文档？

VS Code 在调查受访者中的受欢迎程度似乎在持续增长，从 2021 年以来，表示它是其首选 Go 代码编辑器的受访者比例从 42% 增加到 45%。VS Code 和 GoLand 是最受欢迎的两个编辑器，它们在小型和大型组织中的受欢迎程度没有差异，但业余开发者更倾向于选择 VS Code 而不是 GoLand。此分析不包括随机抽样的 VS Code 受访者——我们预计那些被邀请参加调查的人会偏好用于分发邀请的工具，这正是我们看到的（91% 的随机抽样受访者偏好 VS Code）。

继 2021 年切换到通过 gopls 语言服务器为 VS Code 的 Go 支持提供支持后，Go 团队一直热衷于了解开发者在使用 gopls 方面的痛点。虽然我们从当前使用 gopls 的开发者那里收到了大量反馈，但我们想知道是否有很大一部分开发者在发布后不久就禁用了它，这可能意味着我们没有收到关于特别有问题的用例的反馈。为了回答这个问题，我们询问了那些表示偏好支持 gopls 的编辑器但不使用 gopls 的受访者，发现只有 2% 的人表示已禁用它；对于 VS Code，这一比例降至 1%。这增强了我们听到来自代表性开发者群体的反馈的信心。对于仍未解决 gopls 问题的读者，请通过 在 GitHub 上提交 issue 告知我们。

关于工作区，似乎许多人是通过本次调查才首次了解到 Go 对多模块工作区的支持。通过 VS Code 随机提示得知此调查的受访者尤其有可能表示他们以前从未听说过工作区（53% 的随机抽样受访者 vs. 33% 的自选受访者），这种趋势我们也观察到了对泛型的认知（尽管这两类群体的认知度都更高，93% 的自选受访者知道泛型已包含在 Go 1.18 中，而随机抽样受访者为 68%）。一种解释是，我们通过 Go 博客或现有社交媒体渠道尚未触及大量 Go 开发者受众，而这些渠道一直是我们将新功能分享给大众的主要机制。

我们发现 9% 的受访者表示尝试过工作区，另有 5% 的人希望尝试但被某事阻碍了。受访者在尝试使用 Go 工作区时讨论了各种挑战。缺乏文档和 go work 命令的有用的错误消息名列前茅（21%），其次是技术挑战，如重构现有存储库（13%）。与安全部分讨论的挑战类似，我们再次在此列表中看到了“缺乏时间/非优先事项”——我们将其解释为理解和设置工作区的门槛仍然有点太高，相比它们提供的收益，这可能是因为开发者已经有了替代方案。

在 Go 模块发布之前，组织能够运行内部文档服务器（例如为 godoc.org 提供支持的 服务器），为员工提供私有内部 Go 软件包的文档。使用 pkg.go.dev 仍然是如此，但设置这样的服务器比以前要复杂。为了了解我们是否应该投入精力使这个过程更容易，我们询问了受访者他们今天如何看待内部 Go 模块的文档，以及这是否是他们偏好的工作方式。

结果显示，今天查看内部 Go 文档的最常见方式是阅读代码（81%），并且尽管约有一半的受访者对此感到满意，但仍有很大一部分人希望拥有内部文档服务器（39%）。我们还询问了谁最有可能配置和维护这样的服务器：以 2:1 的比例，受访者认为这将是软件工程师而不是来自专门 IT 支持或运营团队的人。这有力地表明，文档服务器应该是一个即插即用解决方案，或者至少易于单个开发者快速运行（例如，在一个午休时间），理论上这种工作是开发者已经满负荷的又一项职责。

我们听取了谁的意见

总的来说，受访者的个人信息和公司信息与 2021 年调查相比没有显著变化。一小部分受访者（53%）至少有两年使用 Go 的经验，其余的则是 Go 社区的新成员。约 ⅓ 的受访者在小型企业（< 100 名员工）工作，¼ 在中型企业（100 – 1,000 名员工）工作，¼ 在大型企业（> 1,000 名员工）工作。与去年类似，我们发现 VS Code 的提示有助于鼓励北美和欧洲以外的调查参与。

受访者如何使用 Go

与上一节类似，我们没有发现受访者使用 Go 的方式在年复一年之间有统计学上的显著变化。最常见的两种用途仍然是构建 API/RPC 服务（73%）和编写 CLI（60%）。我们使用线性模型来调查受访者使用 Go 的时间长短与他们构建的类型之间是否存在关联。我们发现，有 < 1 年 Go 经验的受访者更有可能在图表中较低的区域构建东西（GUI、IoT、游戏、ML/AI 或移动应用），这表明在这些领域有使用 Go 的兴趣，但一年经验后的下降也暗示着开发者在这些领域使用 Go 时会遇到重大障碍。

大多数受访者在使用 Go 开发时使用 Linux（59%）或 macOS（52%），并且绝大多数部署到 Linux 系统（93%）。本期我们为使用 Windows Subsystem for Linux (WSL) 开发添加了一个回复选项，发现 13% 的受访者在使用 Go 时使用它。

情绪和挑战

最后，我们询问了受访者在过去一年中对 Go 的总体满意度或不满意度，以及他们在使用 Go 时面临的最大挑战。我们发现 93% 的受访者表示“有点”（30%）或“非常”（63%）满意，这与 2021 年 Go 开发者调查中表示满意的 92% 的受访者在统计学上没有显著差异。

多年来，泛型一直是使用 Go 时最常讨论的挑战，Go 1.18 对类型参数的支持最终带来了新的首要挑战：我们老朋友，错误处理。可以肯定的是，错误处理在统计学上与其他几项挑战并列，包括某些领域的库缺失或不成熟、帮助开发者学习和实施最佳实践，以及类型系统的其他修订，例如对枚举的支持或更函数式编程的语法。在泛型之后，Go 开发者似乎面临着一系列长尾挑战。

调查方法

我们于 2022 年 6 月 1 日通过 go.dev/blog 和 Twitter 上的 @golang 公布了本次调查。我们还在 6 月 1 日至 21 日期间通过 Go 插件随机提示了 10% 的 VS Code 用户。调查于 6 月 22 日结束，部分回复（即开始但未完成调查的人）也被记录下来。我们过滤掉了完成调查速度特别快（< 30 秒）或在多选问题中倾向于勾选所有选项的受访者的数据。这留下了 5,752 个回复。

约 ⅓ 的受访者来自随机的 VS Code 提示，与通过 Go 博客或 Go 社交媒体渠道找到调查的人相比，这组人的 Go 经验较少。我们使用线性和逻辑模型来调查这些群体之间明显的差异是否可以通过这种经验差异来更好地解释，通常情况确实如此。例外情况已在文中注明。

今年我们非常希望能够与社区分享原始数据集，类似于 Stack Overflow、JetBrains 等的开发者调查。最近的法律指导不幸阻止了我们现在这样做，但我们正在努力，并有望在下一次 Go 开发者调查中分享原始数据集。

结论

本期 Go 开发者调查重点关注 Go 1.18 版本的新功能。我们发现泛型的采纳进展顺利，开发者已经遇到了一些当前实现上的局限性。模糊测试和工作区的采纳速度较慢，尽管原因主要不是技术性的：两者面临的主要挑战是理解何时以及如何使用它们。开发者缺乏时间关注这些主题也是一个挑战，这一主题也延续到了安全工具方面。这些发现正在帮助 Go 团队确定下一阶段工作的优先级，并将影响我们如何处理未来工具的设计。

感谢您与我们一起游览 Go 开发者研究之旅——我们希望它有所启发且有趣。最重要的是，感谢历年来所有回复我们调查的人。您的反馈帮助我们了解 Go 开发者工作的约束条件，并识别他们面临的挑战。通过分享这些经验，您正在帮助改进 Go 生态系统，造福所有人。代表所有 Gophers，我们感谢您！