2025 Go开发者调查：开发者寻求最佳实践与工具现代化，AI工具应用广但质量担忧导致满意度一般，核心挑战为Go惯用法和可信模块。
译自：Results from the 2025 Go Developer Survey
作者：The Go Blog
你好！在本文中，我们将讨论于2025年9月进行的2025 Go开发者调查的结果。
感谢今年回应我们调查邀请的5,379名Go开发者。您的反馈有助于Google的Go团队和更广泛的Go社区了解Go生态系统的当前状况，并为未来一年的项目确定优先级。
我们的三大主要发现是：
- 总体而言，Go开发者寻求在识别和应用最佳实践、充分利用标准库以及通过更现代的功能扩展语言和内置工具方面获得帮助。
- 大多数Go开发者现在在使用AI驱动的开发工具来获取信息（例如，学习如何使用模块）或进行繁琐工作（例如，编写重复的相似代码块），但由于质量问题，他们对这些工具的满意度一般。
- 令人惊讶的是，很大比例的受访者表示他们经常需要查阅核心
go子命令的文档，包括go build、go run和go mod，这表明go命令的帮助系统有很大的改进空间。
请继续阅读这些发现的详细信息以及更多内容。
我们听取了谁的意见？
大多数受访者自认为是专业开发者（87%），并将Go用于其主要工作（82%）。绝大多数人也将Go用于个人或开源项目（72%）。大多数受访者年龄在25-45岁之间（68%），并拥有至少六年专业开发经验（75%）。更深入地看，81%的受访者告诉我们他们拥有比Go特定经验更多的专业开发经验，这有力地证明Go通常不是开发者使用的第一门语言。事实上，今年调查分析中反复出现的一个主题似乎源于这一事实：当Go中执行任务的方式与更熟悉的语言有很大不同时，它会给开发者带来摩擦，他们需要首先学习对他们来说是新的地道的Go模式，然后在继续使用多种语言时持续记住这些差异。我们稍后会回到这个主题。
受访者工作中最常见的行业是“技术”（46%），但大多数受访者在技术行业之外工作（54%）。我们看到了各种规模组织的代表，略多于一半的人在2-500名员工的公司工作（51%），9%的人单独工作，30%的人在拥有1,000多名员工的企业工作。与往年一样，大多数回复来自北美和欧洲。
今年，我们观察到表示对Go相当陌生、使用Go不到一年时间的受访者比例有所下降（13%，而2024年为21%）。我们怀疑这与行业范围内初级软件工程职位的减少有关；我们经常听到人们说他们为了特定工作而学习Go，因此招聘的下滑预计会减少当年学习Go的开发者数量。我们发现超过80%的受访者是在开始职业生涯之后才学习Go的，这进一步支持了这一假设。
除了上述之外，自2024年调查以来，我们在其他人口统计数据方面没有发现重大变化。
人们对Go的感受如何？
绝大多数受访者（91%）表示他们在使用Go时感到满意。近⅔的人表示“非常满意”，这是最高评分。这两个指标都非常积极，并且自2019年我们开始提出这个问题以来一直保持稳定。随时间推移的稳定性才是我们从该指标中真正监测的内容——我们将其视为滞后指标，这意味着当这个满意度指标显示出有意义的变化时，我们预计已经从问题报告、邮件列表或其他社区反馈中看到了更早的信号。
为什么受访者对Go如此积极？查看对几个不同调查问题的开放文本回复表明，这是一种整体感受，而不是某一件事情。这些人告诉我们，他们发现Go作为一个整体平台具有巨大的价值。这并不意味着它对所有编程领域都同样支持良好（它当然不是），而是开发者重视它通过标准库和内置工具确实良好支持的领域。
以下是受访者的一些代表性引语。为了提供每个引语的背景信息，我们还标注了受访者的满意度、Go使用经验年限和所属行业。
“Go是我迄今为止最喜欢的语言；其他语言感觉太复杂且无用。Go相对较小、简单，功能不多，这一事实在使其成为构建程序的良好持久基础方面发挥了巨大作用。我喜欢它能够很好地适用于单个程序员和大型团队。” — 非常满意 / 10年以上 / 科技公司
“我使用Go的全部原因是其出色的工具和标准库。我非常感谢团队专注于出色的HTTP、加密、数学、同步以及其他使开发面向服务的应用程序变得轻松可靠的工具。” — 非常满意 / 10年以上 / 能源公司
“Go生态系统是我真正喜欢这门编程语言的原因。最近npm有很多问题，但Go没有。” — 非常满意 / 3-10年 / 金融服务
今年我们还询问了人们使用的其他语言。受访者表示，除了Go之外，他们还喜欢使用Python、Rust和TypeScript，以及其他许多语言。这些语言的一些共同特征与Go开发者报告的常见摩擦点相符，包括错误处理、枚举和面向对象设计模式等领域。例如，当我们汇总受访者表示他们第二喜欢的语言包含以下因素之一的比例时，我们发现大多数受访者喜欢使用带有继承、类型安全枚举和异常的语言，而这些语言中只有勉强过半的默认包含静态类型系统。
| 概念或功能 | 受访者比例 |
|---|---|
| 继承 | 71% |
| 类型安全枚举 | 65% |
| 异常 | 60% |
| 静态类型 | 51% |
我们认为这很重要，因为它揭示了开发者所处的更大环境——这表明人们需要根据他们当前正在处理的代码库语言，对相当普通的任务使用不同的设计模式。这不仅给Go新手开发者（他们必须学习地道的Go设计模式）带来了额外的认知负担和困惑，也给许多在多个代码库或项目之间工作的开发者带来了困惑。缓解这种额外负担的一种方法是提供针对特定上下文的指导，例如“Java开发者Go错误处理指南”教程。甚至可能有机会将其中一些指导构建到代码分析器中，使其更容易直接在IDE中浮现。
今年我们请Go社区分享他们对Go项目本身的看法。这些结果与我们上面讨论的91%满意度大相径庭，并指出了Go团队计划在2026年投入精力的领域。特别是，我们希望鼓励更多的贡献者参与进来，并确保Go团队准确理解Go开发者目前面临的挑战。我们希望这种关注反过来有助于提高开发者对Go项目和Go团队领导层的信任。正如一位受访者解释这个问题时所说：
“现在Go团队的创始第一代成员不再过多参与决策，我有点担心Go未来的维护质量，以及迄今为止在语言和标准库更改方面平衡的决策。新的核心团队成员以讲座形式更多地出现，谈论现状和未来计划，可能有助于增强信任。” — 非常满意 / 10年以上 / 科技公司
人们用Go构建什么？
我们修订了2024年的“您用Go构建什么？”列表，旨在更有效地区分人们用Go构建的内容，并避免对“代理”（agents）等演变中的术语产生混淆。受访者最主要的用例仍然是CLI和API服务，自2024年以来两者都没有显著变化。事实上，大多数受访者（55%）表示他们使用Go同时构建CLI和API服务。超过⅓的受访者专门构建云基础设施工具（一个新类别），11%的受访者从事ML模型、工具或代理（一个扩展类别）的工作。不幸的是，嵌入式用例被排除在修订后的列表之外，但我们将在明年的调查中纠正这一点。
大多数受访者表示他们目前没有在他们正在开发的Go软件中构建AI驱动的功能（78%），其中⅔的人报告他们的软件根本不使用AI功能（66%）。这似乎是生产相关AI使用量的同比下降；在2024年，59%的受访者没有参与AI功能工作，而39%的人表示有一定程度的参与。这标志着受访者中构建AI驱动系统的比例下降了14个百分点，可能反映了对AI驱动应用程序早期炒作的一些自然回落：很可能许多人在最初推出时尝试了解这项技术能做什么，其中一部分人决定不再进一步探索（至少目前如此）。
在构建AI或LLM驱动功能的受访者中，最常见的用例是创建现有内容的摘要（45%）。然而，总的来说，大多数用途之间差异不大，28%-33%的受访者添加了AI功能以支持分类、生成、解决方案识别、聊天机器人和软件开发。
Go开发者面临的最大挑战是什么？
我们从开发者那里收到的最有帮助的反馈之一是关于人们在使用Go时遇到的挑战的详细信息。Go团队会从整体上和长远的眼光来考虑这些信息，因为在改进Go的粗糙边缘和保持语言及工具对开发者的一致性之间，通常存在紧张关系。除了技术因素，每一个改变都会在开发者注意力和认知中断方面产生一些成本。最小化中断听起来可能有点乏味或无聊，但我们认为这是Go的一个重要优势。正如Russ Cox在2023年所写，“无聊是好事……无聊意味着能够专注于你的工作，而不是Go的不同之处。”。
本着这种精神，今年的主要挑战与去年没有根本性不同。受访者报告的三大最令人沮丧的问题是“确保我们的Go代码遵循最佳实践/Go惯用法”（33%的受访者）、“我重视的另一门语言的功能不是Go的一部分”（28%）和“寻找值得信赖的Go模块和包”（26%）。我们审查了开放文本回复，以更好地理解人们的意思。让我们花点时间深入探讨每个问题。
对编写地道Go代码感到最沮丧的受访者通常在寻找更官方的指导，以及工具支持来帮助在他们的代码库中强制执行这些指导。与之前的调查一样，关于如何构建Go项目的问题也是一个常见主题。例如：
“Go的简洁性有助于阅读和理解其他开发者的代码，但程序员之间仍然存在一些差异很大的方面。特别是如果开发者来自其他语言，例如Java。” — 非常满意 / 3-10年 / 医疗保健和生命科学
“更具主观性的Go代码编写方式。例如如何为服务/CLI工具构建Go项目。” — 非常满意 / < 3年 / 技术
“很难弄清楚什么是好的惯用法。特别是由于核心团队没有保持Effective Go的更新。” — 非常满意 / 3-10年 / 技术
第二大类令人沮丧的问题是开发者在其他生态系统中喜欢使用的语言功能。这些开放文本评论主要集中在错误处理和报告模式、枚举和和类型、零指针安全以及一般的表达能力/冗长性：
“仍然不确定错误处理的最佳方式是什么。” — 非常满意 / 3-10年 / 零售和消费品
“Rust的枚举非常棒，有助于编写出色的类型安全代码。” — 有点满意 / 3-10年 / 医疗保健和生命科学
“编译器中没有任何东西可以阻止我使用可能为nil的指针，或者在使用值之前不检查错误。这应该[内置]到类型系统中。” — 有点满意 / < 3年 / 技术
“我喜欢[Go]但我没想到它会有空指针异常 :)” — 有点满意 / 3-10年 / 金融服务
“我经常发现很难构建抽象并为代码未来的读者提供清晰的意图。” — 有点不满意 / < 3年 / 技术
第三大令人沮丧的问题是寻找值得信赖的Go模块。受访者经常描述这个问题有两个方面。一是他们认为许多第三方模块质量平平，使得真正优秀的模块难以脱颖而出。二是识别哪些模块是常用模块，以及在何种条件下使用（包括随时间变化的最新趋势）。这两个问题都可以通过在pkg.go.dev上显示我们模糊地称为“质量信号”来解决。受访者提供了他们用来识别值得信赖模块的信号的有用解释，包括项目活跃度、代码质量、最新采用趋势，或者支持或依赖该模块的特定组织。
“能够在pkg.go.dev上按稳定版本、用户数量和上次更新时间等标准进行筛选，可能会让事情变得更容易一些。” — 非常满意 / < 3年 / 技术
“许多包只是克隆/分叉或一次性项目，没有历史/维护。[原文如此]” — 非常满意 / 10年以上 / 金融服务
“也许可以根据经验、成熟度和社区反馈来标记值得信赖的包？” — 非常满意 / 3-10年 / 医疗保健和生命科学
我们同意，这些都是可以改进Go开发者体验的领域。挑战在于，正如前面所讨论的，以一种不会导致破坏性更改、不会增加Go开发者困惑，也不会妨碍人们使用Go完成工作的方式来实现。本次调查的反馈是我们讨论提案时的主要信息来源，但如果您想更直接地参与进来或跟随其他贡献者，请访问GitHub上的Go提案；如果您想添加新提案，请务必遵循此流程。
除了这些（潜在的）生态系统范围的挑战之外，今年我们还专门询问了关于使用go命令的情况。我们非正式地从开发者那里听说，这个工具的帮助系统导航起来可能令人困惑，但我们不清楚人们多久会查阅这份文档。受访者告诉我们，除了go test之外，15%至25%的人在使用这些工具时感觉“经常需要查阅文档”。这令人惊讶，特别是对于像build和run这样常用的子命令。常见原因包括记住特定的标志、理解不同选项的作用以及导航帮助系统本身。参与者还证实，不常使用是令人沮丧的一个原因，但导航和解析命令帮助似乎是根本原因。换句话说，我们都期望有时需要查阅文档，但我们不期望需要帮助来导航文档系统本身。正如一位受访者描述他们的经历：
“获取帮助很痛苦。
go test –help# 不起作用，但告诉我输入go help test…go help test# 哦，实际上，我正在寻找的信息在testflag中go help testflag# 在看起来都一样且没有太多格式的文本中进行视觉解析……我只是没有时间深入研究这个无底洞。” — 非常满意 / 10年以上 / 技术
他们的开发环境是什么样的？
操作系统和架构
总的来说，受访者告诉我们他们的开发平台是类UNIX的。大多数受访者在macOS（60%）或Linux（58%）上进行开发，并部署到基于Linux的系统，包括容器（96%）。最大的同比变化是“嵌入式设备/物联网”部署，从2%增加到8%的受访者；这是自2024年以来部署平台中唯一有意义的变化。绝大多数受访者在x86-64或ARM64架构上进行开发，仍有相当一部分人（25%）可能在32位x86系统上工作。然而，我们认为这个问题的措辞对受访者造成了困惑；明年我们将为每个架构澄清32位与64位的区别。
代码编辑器
过去两年出现了几款新的代码编辑器，我们扩展了调查问题以包含最受欢迎的编辑器。虽然我们看到了一些早期采用的证据，但大多数受访者仍然青睐VS Code（37%）或GoLand（28%）。在新一代编辑器中，Zed和Cursor排名最高，各成为4%受访者首选的编辑器。为了更好地理解这些数字，我们回顾了VS Code和GoLand首次推出时的情况。VS Code（2015年发布）在发布一年后受到16%受访者的青睐。IntelliJ拥有社区主导的Go插件的时间比我们调查Go开发者的时间还要长（💙），但如果我们看看JetBrains何时开始在IntelliJ中正式支持Go（2016年），一年之内IntelliJ就受到20%受访者的青睐。注意：此代码编辑器分析不包括直接从VS Code或GoLand被推荐参与调查的受访者。
云环境
Go最常见的部署环境仍然是亚马逊网络服务（AWS）（46%的受访者）、公司自建服务器（44%）和Google Cloud Platform（GCP）（26%）。这些数字自2024年以来略有变化，但没有统计学意义上的显著性。我们发现今年“其他”类别增加到11%，这主要是由Hetzner（占“其他”回复的20%）驱动的；我们计划在明年的调查中将Hetzner作为回应选项。我们还询问了受访者在使用不同云提供商时的开发体验。然而，最常见的回答表明受访者并不确定（46%）或不直接与公共云提供商互动（21%）。这些回应背后最大的驱动因素是我们之前经常听到的一个主题：通过容器，可以将云环境的许多细节从开发者那里抽象出来，从而使他们无需有意义地与大多数特定于提供商的技术进行交互。这一结果表明，即使是那些工作被部署到云端的开发者，可能也对与每个云提供商相关联的更广泛的工具和技术套件经验有限。例如：
“有点抽象到平台，Go非常容易放入容器，因此非常容易部署到任何地方：这是它的一个大优点。” — [无满意度回复] / 3-10年 / 技术
“云提供商对我来说真的没有太大区别。我编写代码并将其部署到容器中，所以无论是AWS还是GCP我都不太关心。” — 有点满意 / 3-10年 / 金融服务
我们怀疑这种抽象程度取决于所部署服务的使用案例和需求——它可能并非总是合理或能够保持高度抽象。未来，我们计划进一步调查Go开发者如何与其软件最终部署的平台进行交互。
使用AI进行开发
最后，在2025年讨论开发环境时，我们不能不提及AI驱动的软件开发工具。我们的调查表明存在分叉式采用——虽然大多数受访者（53%）表示他们每天使用此类工具，但也有很大一部分人（29%）根本不使用这些工具，或者在过去一个月中只使用了几次。我们曾预期这与年龄或开发经验呈负相关，但除了非常新的开发者之外，我们未能找到强有力证据支持这一理论：拥有不到一年专业开发经验（非Go特定）的受访者确实比其他所有群体报告了更多的AI使用，但这一群体仅占受访者的2%。
目前，AI驱动工具的代理式使用在Go开发者中似乎处于萌芽阶段，只有17%的受访者表示这是他们使用此类工具的主要方式，尽管有更大一部分人（40%）偶尔尝试代理操作模式。
最常用的AI助手仍然是ChatGPT、GitHub Copilot和Claude。与我们2024年的调查相比，这些助手中的大多数显示出较低的使用率（Claude和Cursor是显著的例外），但由于方法论的变化，这并不是一个完全对等的比较。然而，开发者“货比三家”的情况可能比这些工具刚发布时少了，这导致更多人将单一助手用于大部分工作，这是合理的。
我们还询问了对AI驱动开发工具的整体满意度。大多数人（55%）表示满意，但这主要偏向于“有点满意”类别（42%），而不是“非常满意”组（13%）。回想一下，Go本身每年都持续显示90%以上的满意度；今年，62%的受访者表示他们对Go“非常满意”。我们添加这个背景是为了表明，虽然AI驱动的工具正在开始被采用并找到一些成功的用例，但开发者对它们的看法仍然比对更成熟的工具（至少在Go开发者中）要温和得多。是什么导致了这种较低的满意度？一言以蔽之：质量。我们请受访者告诉我们他们用这些工具完成的做得好的事情，以及做得不好的事情。大多数人表示，生成非功能性代码是他们使用AI开发者工具的主要问题（53%），30%的人抱怨即使是能工作的代码质量也很差。相反，最常被提及的好处是生成单元测试、编写样板代码、增强自动补全、重构和文档生成。这些似乎是代码质量被认为不那么关键的情况，从而使AI在任务中首先尝试的优势更大。尽管如此，受访者也告诉我们，在这些成功案例中，AI生成的代码仍然需要仔细审查（并且通常需要修正），因为它可能存在错误、不安全或缺乏上下文。
“我从不满意代码质量或一致性，它从不遵循我想要的实践。” — [无满意度回复] / 3-10年 / 金融服务
“所有AI工具在处理中到大型代码库（1万+行代码）时都容易快速‘幻觉’。它们可以有效地解释代码，但难以生成新的复杂功能。” — 有点满意 / 3-10年 / 零售和消费品
“尽管多次努力让它在一个已有的代码库中编写代码，但要引导它遵循项目中的实践需要付出太多努力，而且它会添加微妙的行为路径——即，如果它遗漏了某个方法，它会尝试绕过它或依赖某些副作用。有时这些事情在代码审查期间很难识别。我还发现审查AI生成的代码在精神上很费力，这种开销扼杀了编写代码的生产力潜力。” — 非常满意 / 10年以上 / 技术
当我们询问开发者他们使用这些工具的目的时，出现了一个与这些质量问题一致的模式。采用率最高（下图中绿色部分）和阻力最小（红色部分）的任务涉及弥合知识鸿沟、改进本地代码和避免繁琐工作。当开发者寻求信息时，例如如何使用特定的API或配置测试覆盖率时，他们对代码生成工具的沮丧感不那么明显，因此，我们在这些领域看到了更高的AI使用率。另一个突出之处是本地代码审查及相关建议——人们对使用AI审查他人代码的兴趣低于审查自己的代码。令人惊讶的是，“测试代码”的AI采用率低于其他繁琐任务，尽管我们目前还不清楚原因。在我们询问的所有任务中，“编写代码”是最两极分化的，66%的受访者已经在使用或希望很快使用AI来完成这项任务，而¼的受访者根本不希望AI参与。开放式回复表明，开发者主要将其用于繁琐、重复的代码，并继续对AI生成的代码质量表示担忧。
结语
再次衷心感谢所有回应今年Go开发者调查的人！
我们计划在2026年第一季度分享原始调查数据集，以便更广泛的社区也能探索这些发现背后的数据。这只会包括选择分享这些数据的人（占所有受访者的82%）的回复，因此可能与本文中引用的数字存在一些差异。
调查方法
本次调查于2025年9月9日至9月30日期间进行。参与者通过Go博客、社交媒体渠道（包括Bluesky、Mastodon、Reddit和X）上的邀请，以及对使用VS Code和GoLand编写Go软件的人的随机产品内邀请，被公开邀请参与调查。我们共收到了7,070份回复。在数据清洗以移除机器人和其他质量非常低的回复后，5,379份回复被用于我们剩余的分析。调查回复的中位时间在12-13分钟之间。在本报告中，我们使用调查回复图表为我们的发现提供支持证据。所有这些图表都采用相似的格式。标题是受访者看到的准确问题。除非另有说明，问题都是多项选择题，参与者只能选择一个答案；每个图表的副标题将告知读者该问题是允许多项选择还是开放式文本框而非多项选择题。对于开放式文本回复的图表，Go团队成员阅读并手动对所有回复进行了分类。许多开放式问题引出了各种各样的回答；为了保持图表大小合理，我们将其浓缩为最多10-12个主题，其余主题均归入“其他”类别。图表中显示的百分比标签四舍五入到最近的整数（例如，1.4%和0.8%都将显示为1%），但每个条的长度和行排序基于未四舍五入的值。为了帮助读者理解每个发现背后的证据权重，我们包含了显示回复95%置信区间的误差条；较窄的条表示更高的置信度。有时两个或多个回复的误差条会重叠，这意味着这些回复的相对顺序没有统计学意义（即，这些回复实际上是并列的）。每个图表的右下角显示了图表中包含的回复人数，格式为“n = [受访者人数]”。
