终结十年纠结:Go 新提案允许 Example 支持任意函数签名

本文永久链接 – https://tonybai.com/2026/06/09/go-proposal-examples-to-support-arbitrary-function-signatures

大家好,我是Tony Bai。

在 Go 语言的开发日常中,编写 ExampleXxx 示例代码不仅是完善文档的必经之路,更是一门绝佳的“活文档”艺术。

通过在 “_test.go” 文件中编写以 Example 开头的函数,并在末尾加上 // Output: 注释,Go 官方的 go doc 和 pkgsite 就能在网页上直接渲染出可交互、可直接在浏览器中运行(Playable)的示例代码。

然而,在这个看似优雅的设计背后,却隐藏着一个让全球 Go 工程师如鲠在喉、折磨了大家近十年的“硬伤”Go 官方对 Example 函数的签名有着极其死板的限制——它必须是无参、无返回值的空函数。

为了这个限制,我们在写文档示例时,不得不写出大量极度违背 Go 地道(Idiomatic)编程哲学的样板代码。

为了彻底拔掉这根刺,Go 编译器团队核心成员Damien Neil (neild)提交了一项被称为“大一统”的提案——Issue #79808:允许 Example 示例支持任意函数签名!

这项提案不仅终结了社区自 2017 年以来的长期争论(#21111 与 #64993),更用一种极其巧妙且务实的“解耦设计”,为 Go 语言的文档生态减负。

历史的疮疤:为了写好一个示例,我们被迫说了多少“废话”?

在真实的 Go 工程中,几乎所有的文件读写、网络调用都会返回 error。按照 Go 的地道写法,当我们调用一个可能失败的函数时,最自然的反应是直接将错误向上抛出:

// 我们真正希望在文档里向用户展示的地道写法
func ExampleReadFile() error {
    data, err := os.ReadFile("config.json")
    if err != nil {
        return err // 优雅直接
    }
    fmt.Println(string(data))
    return nil
}

但是,在目前的 Go 版本中,这行不通! 因为 Example 函数不允许有任何返回值。

为了写出一个能通过 go test 验证的示例,你被迫在你的示例代码中写满各种“废话”:

// 迫于规则,我们不得不写出的妥协版本
func ExampleReadFile() {
    data, err := os.ReadFile("config.json")
    if err != nil {
        log.Fatal(err) // 或者使用更难看的 panic(err)
    }
    fmt.Println(string(data))
    // Output: { "port": 8080 }
}

这带来了一个极其糟糕的引导效应:新手在阅读官方文档时,会误以为在业务代码中遇到错误就应该直接 log.Fatal 或 panic。 示例代码不仅没能展示出 Go 语言优雅的错误处理哲学,反而成了不良编码习惯的传染源。

此外,当你在编写测试框架(Test Framework)或者使用 Go 新版引入的 synctest 虚拟时钟技术时,你必须拿到底层的 *testing.T 对象。但由于 Example 函数不能有入参,你根本无法写出一个可以传递 t *testing.T 对象的示例代码。

十年博弈:从 #21111 到 #64993 的宿命碰撞

为了解决这两个痛点,Go 社区实际上进行了两场旷日持久的战役:

战役 1:允许 Example 返回 error(#21111 – 始于 2017 年)

早在 2017 年,大牛 rogpeppe 就提出了这个想法。但当时官方为了等待 Go 2 的整体错误处理方案(Error Handling Draft)而将其无限期搁置。随着 Go 错误语法提案被无限期延迟,这个 hold 也终于在近年被拿掉。

战役 2:允许入参带上 *testing.T(#64993 – 始于 2024 年)

随着多智能体测试和 synctest(需要虚拟时间同步)等现代测试技术的发展,开发者越来越需要展示涉及 testing.T / testing.B / testing.F 的完整用例。但因为不支持入参,大家不得不写出复杂的 Stub(伪造类)去强行拼凑。

大一统方案 #79808:允许任意函数签名的 Example!

面对这两个互相纠缠、细节极其复杂的提案,Go 核心团队的 neild 指出,之前的讨论之所以陷入死胡同,是因为大家把 “文档如何展示示例(Rendering)”“测试框架如何运行示例(Execution)” 混为一谈了。

如果我们彻底将这两者解耦呢?

Issue #79808 中,他提出了一个近乎完美的极简方案:对 Example 函数的签名彻底放开限制。

1. 规则大解放

只要你的函数命名符合 Example 或 ExampleXxx(且首字母大写),go doc 和 pkgsite 就会一律无条件地将其作为示例代码在网页上展示出来!

无论你的函数长成什么样:

package example_test

// 场景 A:优雅返回 error,不再需要 log.Fatal
func Example_returning_an_error() error {
    f, err := os.Open("testfile")
    if err != nil {
        return err
    }
    defer f.Close()
    return nil
}

// 场景 B:支持传入 testing.T,测试框架类的完美示范
func ExampleFunc_taking_a_t(t *testing.T) {
    if err := examplepackage.Func(t); err != nil {
        t.Fatal(err)
    }
}

// 场景 C:甚至可以带上输入输出参数
func Example_in_and_out(a, b int) string {
  return examplepackage.AddReturningString(a, b)
}

2. 完美的运行防线

如果放开了签名限制,go test 怎么运行它们?

  • 对于有参数或返回值的 Example:testing 包一律不自动运行它们。这极大地简化了测试运行器的复杂度,避免了处理带有复杂入参的函数执行。
  • 防止混淆:如果一个 Example 带有入参或返回值,但你却在末尾写了 // Output: 注释,go test 会直接抛出编译期错误,防止开发者产生误解。
  • 如何跑测试?:如果你依然希望在测试中运行这些复杂的示例,非常简单,写一个伴随的 Test… 函数手动调用它即可:
func TestExample_returning_an_error(t *testing.T) {
  if err := Example_returning_an_error(); err != nil {
    t.Fatal(err)
  }
}

小结:让代码回归纯粹

从这个跨越十年的提案博弈中,我们能清晰地感受到 Go 团队的实用主义工程哲学:

他们没有为了解决问题而去创造一套复杂的、充满各种边界特例的编译器黑魔法,而是通过“将文档展示与执行引擎完全剥离”这一解耦思路,在不增加运行时负担的前提下,完美解决了长期折磨开发者的体验难题。

让文档回归原本纯粹的模样,让代码不再为古板的规则而妥协。这也是 Go 语言吸引系统工程师的魅力所在。

资料链接:

  • https://github.com/golang/go/issues/21111
  • https://github.com/golang/go/issues/64993
  • https://github.com/golang/go/issues/79808

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策?我的新专栏 从0 开始构建 Agent Harness 将带你:

  • 抛弃臃肿框架,回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等,复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码,开启从 0 开始构建Agent Harness 的实战之旅。


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

2026年,大厂重构核心系统为何集体投向 Go?

本文永久链接 – https://tonybai.com/2026/06/08/the-real-reason-big-tech-is-switching-to-go

大家好,我是Tony Bai。

在软件工程中,核心技术栈的迁移是一项高风险、高成本的决策。

然而,在近期的技术演进中,我们看到了一股明显的趋势:全球科技巨头与快速成长的 AI 独角兽们,正在不约而同地将核心系统向 Go 语言(Golang)收敛。

  • 微软宣布将 TypeScript 核心编译器移植到 Go,构建速度暴涨 10 倍。
  • Reddit将庞大的 Python 单体架构逐步解耦,核心数据模型全面改用 Go 重写。
  • Lovable(前沿 AI 独角兽)将 4.2 万行 Python 代码移植为 Go,服务器实例直接从 200 个锐减到 10 个。
  • Uber作为长期拥有最庞大 Go 代码库的企业之一,持续将后端服务从 Python、Node.js 收敛、统一至 Go 语言,以极低的算力成本承载海量并发。

这并非盲目的技术跟风,而是一场基于运行成本、高并发能力和工程维护性的理性重构。今天,我们就通过这些大厂的真实工程案例,深入拆解大厂重构核心系统时,集体投向 Go 的底层逻辑与技术启示。

微软的编译器移植:为什么 C# 之父不选 C# 和 Rust?

2025 年 3 月,微软宣布将 TypeScript 的编译器和工具链移植到 Go 语言。到了 2026 年 4 月,采用 Go 编译器底层的 TypeScript 7 Beta 正式发布。

令人瞩目的是,这个项目的操盘手正是 Anders Hejlsberg —— C# 语言的设计者TypeScript 的创造者

这一决策在技术社区引发了深度探讨:为什么微软不用自家的 C#,也没有选择近年来大热的 Rust?这背后隐藏着极具启发性的工程权衡。

明确“移植(Port)”与“重写(Rewrite)”的边界

在工程决策中,这两者有着本质区别:

  • 完全重写(Rewrite):意味着抛弃旧代码,从零开始重新设计(New Design),风险极高。
  • 代码移植(Port):翻译现有代码,保持原有的代码结构和行为(Same behavior & structure),风险可控。

旧的 TypeScript 编译器是用函数式风格编写的,且重度依赖垃圾回收(GC)

  • 为什么不选 C#?C# 是典型的面向对象(OOP)语言。如果使用 C#,将很难平滑移植函数式风格的旧编译器,几乎等同于要推倒重写。
  • 为什么不用 Rust?Rust 没有垃圾回收机制,要求开发者手动且极其严苛地管理内存。如果改用 Rust,团队必须彻底推翻并重新设计整套代码的内存生命周期,这直接背离了“平滑移植”的初衷。

Go 为什么是最佳折中方案?

Go 既支持原生编译,拥有极高的运行速度,同时还内置了高效的垃圾回收(GC)。

更关键的是,习惯写法的 Go 代码(Idiomatic Go)在结构上与 TypeScript 原有的编码模式有着天然的相似性。这使得原有团队在维护移植后的 Go 代码时,几乎没有认知摩擦。

移植后的性能收益:
* 编译构建速度直接提升了 10 倍
* 编辑器加载时间从原来的 9.5 秒缩短至 1.2 秒

微软用事实证明:Go 是在维持原有代码结构的前提下,实现性能跨越式提升的最短路径。

Reddit 的解耦之路:高并发压力下的“影子测试”

Reddit 曾长期使用 Python 单体(Monolith)架构。随着全球流量的爆发,单体架构的弊端逐渐显现:代码耦合严重、可靠性降低,系统维护成本极高。在高峰期,甚至连发帖、评论等基础操作都会遭遇严重的延迟。

为了解决高并发瓶颈,Reddit 决定对核心的四大基础特性(评论、账户、帖子、子社区)进行解耦,全部用 Go 语言重写为独立的微服务。

为什么选择 Go?

在高并发场景下,Go 内置的轻量级协程(Goroutine)和通道(Channel)调度模型,相比于 Python 的多线程/多进程,能够以更低的系统开销和更少的网络协调,抗住同等规模的流量。

零故障上线的“影子测试(Shadow Testing)”

系统重构最忌讳“一刀切”式的直接上线。Reddit 采用了一套精妙的过渡方案:

他们让 Python 旧单体Go 新服务在后台同时运行。对于每一次写入请求,两个系统都会收到相同的输入。Go 服务将数据写入一个隔离的测试数据库。

               ┌───────────────┐
               │  User Input   │
               └───────┬───────┘
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
    ┌─────────────────┐ ┌─────────────────┐
    │ Python Monolith │ │   Go Services   │
    └────────┬────────┘ └────────┬────────┘
             ▼                   ▼
    ┌─────────────────┐ ┌─────────────────┐
    │  Production DB  │ │     Test DB     │
    └─────────────────┘ └─────────────────┘
             │                   │
             └─────────┬─────────┘
                       ▼
             Compare & Debug Output

通过在后台持续对比两个系统的输出结果,团队在不影响真实用户的前提下,排查并修复了新服务中的所有潜在 Bug。确认无误后,才 100% 将流量平滑切换到了 Go 服务。

重构后的收益:
* 关键写入操作的 P99 延迟直接砍半,系统高可用性大幅提升。

运行成本与算力优化:Lovable 与 Uber 的工程实践

对于快速成长的 AI 独角兽 Lovable 来说,技术栈的选择直接关系到服务器账单和业务存亡。

作为一个允许非技术用户通过 AI 构建应用的平台,Lovable 在核心链路上面临着极高并发的挑战。用户发送一条聊天指令,后台需要瞬间触发超过 50 个 HTTP 并发调用,分别去请求各大模型提供商、内部存储及周边服务。

Python 在这种高度并行的 IO 密集型场景下显得力不心。Lovable 团队果断将 4.2 万行 Python 代码重写为 Go

无独有偶,Uber 作为长期拥有最庞大 Go 代码库的企业之一,也曾经历过从 Python、Node.js 向 Go 逐步收敛的过程。为了在单机上压榨出更高的并发能力,减少冗余的服务器开销,Uber 逐步在后端服务中停用了 Python,将核心服务统一收敛至 Go。

这两家公司,用 Go 实现了令人惊叹的算力优化:

小结:大厂系统重构释放的工程信号

这些大厂和独角兽们的集体实践,为我们释放了清晰的工程信号:

  1. “运行成本”正成为系统重构的首要驱动力
    在项目初期,动态语言(如 Python、TypeScript)确实能提供极佳的开发爽感。但当业务规模扩大、高并发场景增加时,其带来的服务器硬件成本和维护开销将呈指数级上升。
  2. Go 处于“开发效率”与“运行性能”的黄金分割点
    它不像 Rust 那样有着极其陡峭的内存管理和所有权学习曲线,能够让团队保持极高的开发效率;同时,它又拥有接近原生代码的执行速度,和冠绝群雄的轻量级并发模型。这使其成为了现代生产级后端服务的首选。

大厂的重构实践,为我们提炼了以下三条黄金工程铁律:

  1. 分清“移植”与“重写”:在系统重构时,若想在保留原有业务逻辑的前提下快速提升性能,像微软那样进行代码级移植(Port)是风险最低、效率最高的路径。
  2. 善用“影子测试(Shadow Testing)”:核心系统解耦和替换时,切忌盲目上线。采用双轨并行、对比输出的影子测试,是保障系统平滑过渡、零故障上线的最佳实践。
  3. 高并发场景首选轻量并发模型:当系统面临大量并发 IO(如 AI 编排、多 API 协同调用)时,Go 语言的协程机制能够以极低的资源消耗提供极佳的吞吐量。

系统重构的本质,是在业务发展、团队认知和机器成本之间寻找最优解。而 Go,正是大厂在经历数次工程实践后,给出的最务实的答案。

资料链接:https://www.youtube.com/watch?v=-Z813pHqSFI


今日开放讨论:

  1. 微软不用 C# 也不用 Rust,而是选择 Go 来移植 TS 编译器,这个决策中的“移植 vs 重写”权衡是否启发了你?
  2. Reddit 采用的“双轨制影子测试”非常稳健,你在实际的系统迁移或重构中,使用过类似的测试方案吗?
  3. 从 Lovable 将 200 个实例缩减为 10 个,到 Uber 节省 97% 的算力,这些真实的性能与成本数据是否改变了你对后端技术选型的看法?

欢迎在评论区留下你的硬核观点,我们一起探讨系统重构与 Go 的工程之美!


还在为写 Agent 框架频频死循环、上下文爆炸而束手无策?我的新专栏 从0 开始构建 Agent Harness 将带你:

  • 抛弃臃肿框架,回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等,复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码,开启从 0 开始构建Agent Harness 的实战之旅。


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 从 0 开始构建 Agent Harness Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com
这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats