
本次 2025 年度 Go 开发者调研共有 5,379 名开发者参与。调研结果揭示了 Go 生态系统的现状,为后续的项目优先级提供了重要参考。
以下是三大核心发现:
- 开发者普遍希望在识别与应用最佳实践方面获得更多支持,进一步挖掘标准库的潜力,并期待 Go 语言及内置工具链能够引入更多现代化特性。
- 大多数 Go 开发者已开始在信息检索(如学习模块用法)和处理重复性劳动(如编写样板代码)时使用 AI 辅助开发工具。然而,受限于生成质量等问题,开发者对这些工具的满意度目前处于中等水平。
- 调研显示,高频查阅 go build、go run 和 go mod 等核心子命令文档的受访者比例惊人。这表明 go 命令的内置帮助系统仍有巨大的改进空间。
核心章节
- 受访者画像[1]
- Go 语言满意度[1]
- Go 应用场景[1]
- 开发者面临的挑战[1]
- 开发环境配置[1]
- 调研方法论[1]
受访者画像
绝大多数受访者为职业开发者(87%),其中 82% 在主职工作中使用 Go。同时,很大一部分比例(72%)也会在个人项目或开源项目中使用 Go。受访者的年龄段主要集中在 25 - 45 岁(68%),且 75% 拥有至少六年的职业开发经验。深入分析发现,81% 的受访者职业开发经验长于 Go 的使用经验,这有力地证明了 Go 通常不是开发者的入门语言。事实上,今年调研中反复出现的一个核心痛点也源于此:当 Go 处理任务的方式与开发者熟悉的语言有显著差异时,会产生认知摩擦——他们需要先学习新的 Idiomatic Go(地道 Go 模式),并在多语言并行的开发环境中不断强化这些差异记忆。
在行业分布上,“技术”行业占比最高(46%),但仍有超过半数(54%)的受访者在非技术行业工作。组织规模方面分布均匀:51% 的受访者就职于 2 - 500 人规模的公司,9% 为独立开发者,30% 则效力于千人以上的大型企业。地理分布上,大部分反馈依然来自北美和欧洲地区。
今年,Go 经验不足一年的新手比例有所下降(从 2024 年的 21% 降至 13%)。这可能与全行业初级软件工程师职位的减少[2]有关;调研显示,许多人是因工作岗位需求而学习 Go,因此招聘市场的降温直接影响了当年学习 Go 的开发者数量。超过 80% 的受访者是在开启职业生涯之后才开始学习 Go 的,这一数据进一步印证了上述假设。
除此之外,其他人口统计学特征与 2024 年调研相比未发现显著变化。








Go 开发者满意度调研
绝大多数受访者(91%)表示对使用 Go 语言感到满意。其中近 2/3 的人选择了“非常满意”,这是最高级别的评价。这两项指标都非常积极,且自 2019 年开始调研以来一直保持稳定。我们长期关注这一指标的稳定性,并将其视为一种滞后指标——这意味着,如果满意度发生显著变化,我们通常已经能从问题报告、邮件列表或其他社区反馈中察觉到早期信号。

受访者为何对 Go 评价如此之高?通过对多个调研问题的开放性回答进行分析,我们发现这更多源于一种整体感受,而非单一特性。开发者认为 Go 作为一个整体平台具有巨大的价值。这并不意味着它在所有编程领域都表现卓越(事实并非如此),但开发者非常看重 Go 通过标准库(stdlib)和内置工具链在特定领域提供的强力支持。
以下是部分受访者的代表性评价。为了便于理解,我们标注了受访者的满意度、Go 使用年限以及所属行业:
“Go 是目前我最喜欢的语言;其他语言感觉过于复杂且不够实用。Go 相对精简、简单,没有过多的花哨功能,这使其成为构建程序的稳固基石。我非常喜欢它在个人开发者和大型团队之间出色的扩展性。” —— 非常满意 / 10 年以上经验 / 科技公司
“我使用 Go 的全部原因在于其出色的工具链和标准库。非常感谢团队专注于提供优秀的 HTTP、crypto、math、sync 等工具,这些工具让开发面向服务的应用变得既简单又可靠。” —— 非常满意 / 10 年以上经验 / 能源公司
“Go 生态系统是我真正热爱这门语言的原因。最近 npm 出了很多问题,但 Go 却没有。” —— 非常满意 / 3-10 年经验 / 金融服务业
今年我们还调查了开发者使用的其他语言。受访者表示,除 Go 之外,他们还喜欢使用 Python、Rust 和 TypeScript 等。这些语言的一些共同特征与 Go 开发者反馈的常见痛点高度吻合,包括错误处理、枚举(enums)和面向对象设计模式等领域。例如,通过统计受访者最喜欢的其他语言所包含的特性,我们发现大多数受访者习惯于使用支持继承、类型安全枚举和异常处理(exceptions)的语言,而这些语言中仅有半数默认包含静态类型系统。
| 特性或功能 | 受访者占比 |
|---|---|
| 继承 (Inheritance) | 71% |
| 类型安全枚举 (Type-safe enums) | 65% |
| 异常处理 (Exceptions) | 60% |
| 静态类型 (Static typing) | 51% |
我们认为这一点非常重要,因为它揭示了开发者所处的宏观环境——这意味着开发者需要根据当前代码库的语言,为一些相当基础的任务切换不同的设计模式。这不仅会给 Go 新手(需要学习惯用的 Go 设计模式)带来额外的认知负荷和困惑,对于那些多语言并行的开发者也是如此。减轻这种负担的一种方法是提供特定背景的指南,例如“面向 Java 开发者的 Go 错误处理教程”。甚至可以将这些引导逻辑集成到代码分析器中,直接在 IDE 中进行提示。

今年我们还调研了社区对 Go 项目本身的看法。结果与上述 91% 的满意度有所不同,这指出了 Go 团队在 2026 年计划投入精力的方向。具体而言,我们希望鼓励更多贡献者参与进来,并确保团队能够准确理解开发者当前面临的挑战。我们希望通过这些努力,进一步提升开发者对 Go 项目及领导层的信任。正如一位受访者所言:
“鉴于 Go 团队的第一代初创成员已不再深入参与决策,我对 Go 未来的维护质量,以及语言和标准库变更决策的平衡性感到有些担忧。如果核心团队的新成员能通过更多演讲来展示当前现状和未来规划,或许有助于增强大家的信心。” —— 资深开发者(10 年以上经验)/ 科技公司

Go 应用领域分析
我们对 2024 年“使用 Go 构建的应用类型”列表进行了修订,旨在更清晰地划分 Go 的应用场景,并避免在“智能体 (Agents)”等演进术语上产生歧义。受访者的核心用例依然是 CLI(命令行工具)和 API 服务,较 2024 年没有显著变化。事实上,多数受访者 (55%) 表示会同时使用 Go 构建这两种应用。超过 1/3 的受访者专门构建云基础设施工具(新增类别),11% 的受访者涉及机器学习模型、工具或智能体(扩展类别)。

大多数受访者表示目前并未在 Go 软件中构建 AI 驱动的功能 (78%),其中 2/3 的受访者表示其软件完全不涉及 AI 功能 (66%)。与去年相比,生产环境中的 AI 采用率似乎有所下降:2024 年有 59% 的受访者未参与 AI 功能开发,而 39% 表示有不同程度的参与。今年这一比例下降了 14 个百分点,这可能反映出市场对 AI 炒作的自然回落:很多人在技术发布初期进行了尝试,但随后有一部分人决定暂缓进一步探索。

在正在构建 AI 或大语言模型 (LLM) 功能的受访者中,最常见的用例是内容摘要 (45%)。总体而言,其他用例的分布较为平均,占比在 28% 到 33% 之间,主要涵盖分类、内容生成、方案识别、聊天机器人以及辅助软件开发等功能。

Go 开发者面临的主要挑战
Go 团队通过收集开发者在实际工作中遇到的挑战,来平衡改进语言缺陷与保持工具链一致性之间的关系。除了技术因素,任何变更都会带来认知成本。正如 Russ Cox 在 2023 年所言:“平庸(Boring)是好事。平庸意味着你可以专注于工作,而不是纠结于 Go 的差异化。”
今年的调研显示,排名前三的痛点分别是:“确保代码符合最佳实践/地道用法(Idiomatic Go)”(33%)、“缺失其他语言中的优秀特性”(28%)以及“寻找可靠的 Go 模块与包”(26%)。
编写地道的 Go 代码
开发者对编写地道代码的困惑主要集中在缺乏官方指南以及缺乏强制执行这些规范的工具支持。关于如何组织 Go 项目结构依然是一个高频话题:
“Go 的简洁性有助于阅读他人代码,但不同背景(如 Java)的开发者写出的代码风格差异依然很大。”
“希望能有更具‘意见倾向(Opinionated)’的编写方式,比如针对 Service 或 CLI 工具如何组织项目结构。”
“很难确定哪些才是好的惯用法,尤其是官方的《Effective Go》文档更新并不及时。”
语言特性的缺失
第二大类挑战源于开发者对其他语言生态中某些特性的青睐。反馈主要集中在错误处理模式、枚举(Enums)与和类型(Sum Types)、空指针安全(Nil Pointer Safety)以及表达能力(代码冗长)等方面:
“依然不确定错误处理的最佳实践是什么。”
“Rust 的枚举非常棒,能引导开发者写出类型安全的代码。”
“编译器无法阻止我使用可能为 nil 的指针,或者在检查错误前就使用返回值。这应该集成在类型系统中。”
“我喜欢 Go,但没想到它居然还会有空指针异常。”
“有时很难构建抽象,并向代码的后续阅读者清晰地传达意图。”
寻找可靠的模块
关于寻找可靠模块的挫败感主要源于两个维度:一是第三方模块质量参差不齐,导致优秀模块难以脱颖而出;二是难以识别哪些模块是主流选择及其应用场景(包括近期的流行趋势)。开发者建议在 pkg.go.dev 上展示“质量信号”,例如项目活跃度、代码质量、采用趋势或背书机构:
“如果 pkg.go.dev 能支持按稳定版本、用户量和最后更新时间进行过滤,情况会好很多。”
“许多包只是克隆、Fork 或者是没有维护记录的一次性项目。”
“是否可以根据经验、成熟度和社区反馈来标记可靠的包?” Go 开发者体验在多个领域仍有提升空间。目前的挑战在于,如何在改进的同时避免引入破坏性变更(breaking changes),不增加开发者的认知负担,且不干扰现有的开发流程。GitHub 上的 Go proposals[3] 是追踪技术提案的主要渠道;若需提交新提案,请遵循此流程规范[4]。

除了生态层面的挑战,今年还针对 go 命令的使用体验进行了调研。此前有反馈指出该工具的帮助系统(help system)导航较为混乱,但尚不明确开发者查阅相关文档的具体频率。
调研结果显示,除 go test 外,约 15% - 25% 的受访者表示在操作相关工具时“经常需要查阅文档”。对于 build 和 run 这种高频子命令,这一比例超出了预期。主要原因包括:难以记忆特定参数(flags)、不理解选项的具体功能,以及帮助系统本身的导航体验不佳。虽然使用频率低是导致挫败感的原因之一,但导航和解析命令帮助信息才是核心痛点。开发者普遍接受需要查阅文档,但不希望在“如何使用帮助系统”本身上浪费时间。正如一位受访者所述:
“获取帮助信息的过程非常痛苦。执行 go test -help 没用,它提示我输入 go help test。执行 go help test 后,发现想要的信息其实在 testflag 里。再执行 go help testflag,面对的是一大堆缺乏格式化、难以视觉解析的纯文本。我实在没时间去钻这种深坑。” —— 资深开发者 / 技术领域 / 10 年以上经验

开发环境概况
操作系统与架构
调研结果显示,受访者的开发平台普遍具有类 UNIX 特性。大多数开发者在 macOS (60%) 或 Linux (58%) 上进行开发,并将其部署到 Linux 系统(包括容器,占比达 96%)。同比变化最明显的是“嵌入式设备 / IoT”部署,占比从 2% 增长至 8%,这也是自 2024 年以来部署平台方面唯一显著的变化。
绝大多数受访者在 x86-64 或 ARM64 架构上进行开发,仍有相当一部分群体 (25%) 可能在 32 位 x86 系统上工作。



代码编辑器
尽管过去两年涌现了多个新编辑器,且部分已被早期采用者使用,但大多数受访者仍青睐 VS Code[5] (37%) 或 GoLand[6] (28%)。在新兴编辑器中,Zed 和 Cursor 排名最高,各占 4% 的份额。作为对比,VS Code(2015 年发布)在发布一年后获得了 16% 的支持率;JetBrains 自 2016 年正式支持 Go 语言后,IntelliJ 在一年内便获得了 20% 用户的认可。
注:此编辑器分析排除了直接通过 VS Code 或 GoLand 链接参与调研的受访者。

云环境
Go 最常见的部署环境依然是 Amazon Web Services (AWS) (46%)、公司自建服务器 (44%) 以及 Google Cloud Platform (GCP) (26%)。与 2024 年相比,这些数据波动较小。值得注意的是,“其他”类别今年上升至 11%,主要由 Hetzner 驱动(占“其他”响应的 20%)。
在云平台开发体验方面,46% 的受访者表示不确定,21% 的受访者不直接与公有云提供商交互。这主要归功于容器化技术:通过容器可以屏蔽云环境的底层细节,使开发者无需深入接触特定提供商的技术栈。这意味着即便软件部署在云端,开发者对云平台相关工具链的直接经验可能也比较有限。例如:
“平台层面对我来说是抽象的。Go 非常容易容器化,因此部署到任何地方都很方便:这是它的核心优势之一。” —— [无满意度评价] / 3 - 10 年经验 / 技术行业
“云提供商对我来说真的没什么区别。我只管写代码并部署到容器中,无论是 AWS 还是 GCP,我并不在乎。” —— 比较满意 / 3 - 10 年经验 / 金融服务
这种抽象程度取决于具体的业务场景和服务需求,在某些情况下,保持高度抽象可能并不现实或并非最优解。


AI 辅助开发
谈及 2025 年的开发环境,AI 驱动的软件开发工具已成为不可忽视的一环。调查结果呈现出两极分化的趋势:虽然多数受访者(53%)表示每天都会使用此类工具,但仍有相当一部分人群(29%)完全不使用,或在过去一个月中仅试用过几次。此前我们预测 AI 的使用频率可能与年龄或开发经验成负相关,但数据并未提供有力支撑。唯一的例外是“极新手”群体:职业开发经验(不仅限于 Go)不足一年的受访者使用 AI 的频率高于其他任何群体,不过该群体仅占总受访者的 2%。

目前,Go 开发者对 AI Agent(智能体)的使用尚处于起步阶段。仅有 17% 的受访者将其作为主要使用方式,不过有较大比例(40%)的开发者正在偶尔尝试 Agent 模式。

ChatGPT、GitHub Copilot 和 Claude 依然是最常用的 AI 助手。与 2024 年的调查结果[7]相比,大多数工具的使用率有所下降(Claude 和 Cursor 除外),但由于统计方法的调整,这并非完全对等的比较。一个合理的推测是,开发者不再像这些工具刚发布时那样频繁地“货比三家”,而是逐渐固定使用某一款助手来完成大部分工作。

关于 AI 开发工具的整体满意度,多数受访者(55%)表示满意,但其中“比较满意”(42%)的比例远高于“非常满意”(13%)。相比之下,Go 语言本身的满意度每年都稳定在 90% 以上,今年更有 62% 的受访者表示对 Go “非常满意”。这表明虽然 AI 工具已开始普及并应用于某些场景,但开发者对其认可度仍远不及成熟的开发工具(至少在 Go 开发者群体中如此)。
导致满意度不高的核心原因在于“质量”。在关于 AI 工具优缺点的反馈中,53% 的受访者认为“生成无法运行的代码”是首要问题,30% 的人抱怨即便代码能跑,质量也很差。相反,被提及最多的正面场景包括:生成单元测试、编写样板代码(Boilerplate)、增强型代码补全、重构以及生成文档。这些场景的共同点是开发者对代码质量的敏感度相对较低,因此更愿意让 AI 先打个草稿。即便如此,受访者强调,即便是成功案例,生成的代码仍需经过严格的人工审查和修正,因为它们可能存在 Bug、安全隐患或缺乏上下文。
“我对代码质量和一致性从未满意过,它永远无法遵循我想要的实践规范。” —— [未填写满意度] / 3 - 10 年经验 / 金融服务业
“在处理中大型代码库(1 万行代码以上)时,所有 AI 工具都很容易出现幻觉。它们解释代码很有效,但在生成新的复杂功能时非常吃力。” —— 比较满意 / 3 - 10 年经验 / 零售与消费品业
“尽管多次尝试让它在现有代码库中写代码,但引导它遵循项目规范实在太费劲了。它还会引入微妙的行为路径——比如漏掉某个方法时,它会尝试绕过它或者依赖某些副作用。这些问题在 Code Review 时很难发现。我发现审查 AI 生成的代码非常耗费精力,这种开销抵消了它带来的生产力提升。” —— 非常满意 / 10 年以上经验 / 技术行业
在对开发者使用 AI 工具的调研中,我们发现其应用模式与代码质量相关。采用率最高(图中绿色部分)且阻力最小(红色部分)的任务主要集中在弥补知识差距、优化本地代码以及减少重复劳动。开发者在寻求信息(如特定 API 的用法或配置测试覆盖率)时,对 AI 生成代码工具的抵触感明显降低,因此这些领域的 AI 使用率更高。另一个值得关注的点是“本地”代码审查及相关建议——相比于让 AI 审查他人的代码,开发者更倾向于用它来检查自己的代码。令人意外的是,“编写测试代码”的 AI 采用率低于其他繁琐任务,其背后的深层原因尚不明确。
在所有调研任务中,“编写代码”的分歧最为显著:66% 的受访者已经或希望使用 AI 辅助编程,而 25% 的受访者则完全不希望 AI 介入。开放式回答显示,开发者主要将 AI 用于编写繁琐、重复的代码,并持续对 AI 生成代码的质量表示担忧。

调研方案
本次调研于 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% 置信区间[8] 的误差线;误差线越窄,代表可信度越高。若两个或多个选项的误差线重叠,则说明其相对顺序在统计学上无显著差异(即处于持平状态)。图表右下角的 “n = [受访者人数]” 表示该图表包含的有效样本量。
#Go语言 #开发者调查 #AI工具 #软件工程 #技术趋势

引用链接
- https://go.dev/blog/survey2025
- https://digitaleconomy.stanford.edu/wp-content/uploads/2025/08/Canaries_BrynjolfssonChandarChen.pdf
- https://github.com/golang/go/issues
- https://github.com/golang/proposal
- https://code.visualstudio.com/
- https://www.jetbrains.com/go/
- https://go.dev/blog/survey2024-h2-results
- https://en.wikipedia.org/wiki/Confidence_interval


