本文永久链接 – https://tonybai.com/2025/08/12/go-identity-crisis

大家好，我是Tony Bai。

最近，在国外的 Go 社区（Reddit r/golang）上，一个帖子引发了我的深思。发帖者是一位资深的 Gopher，他用一种略带困惑的语气写道：

“我感受到来自新 Go 开发者的巨大压力，他们想把 Go 变成他们最喜欢的语言。”

他列出了一份“愿望清单”，上面是新 Gopher 们最常要求增加的特性：

• 注解 (Annotations)，像 Java 或 Python 那样
• 更多原生类型，比如 Set、Stream
• 三元运算符
• 元编程能力

同时，他还观察到了一些行为模式：引入大量依赖来完成简单的任务、用熟悉的 Java 式架构来封装地道的 Go 行为、甚至完全不使用强大的标准库……

这个帖子像一块石头投入了平静的湖面，瞬间激起了数百条评论。这不仅仅是一场关于“增加什么功能”的技术讨论，它更像是一场关于 Go 语言“我是谁？”、“我从哪里来？”、“我要到哪里去？”的哲学辩论。

这，正是 Go 语言正在经历的一场深刻的“身份危机”。

“原住民” vs “新移民”的哲学冲突

要理解这场危机的本质，我们可以把 Go 社区形象地看作一个正在迅速发展的“新大陆”。这里有两类居民：

• “原住民” (The Natives)：他们是早期来到这片大陆的开拓者，被 Go 语言最初的承诺所吸引——简单、明确、可预测。他们选择 Go，正是因为它打破了传统语言不断堆砌特性、直到每个人都满意的怪圈。
• “新移民” (The Immigrants)：随着 Go 的成功，大量来自 Java、Python、Ruby 等繁华“旧大陆”的开发者涌入。他们带来了丰富的经验和不同的编程习惯，同时也带来了对故乡那些“便利设施”的怀念。

这场冲突，本质上是“原住民”的简约哲学与“新移民”的表达力期望之间的碰撞。

“原住民”的坚守：可预测性是第一原则

对于老 Gopher 来说，Go 的核心价值在于它的可预测性。这意味着更少的“魔法”，更低的认知复杂度。

一篇评论精辟地指出：

“Go 想要的是一种更像扁平封装家具（flat pack furniture）的语言，而不是复杂的工程学。它追求的是：可预测、一致、简单、坚固。”

我们都知道，软件的 Bug 数量，往往不与代码行数（LOC）成正比，而是与认知复杂度成正比。Go 的哲学，就是宁愿增加一些可见的、重复的代码（比如经典的 if err != nil），也要换取认知复杂度的显著降低。当你阅读一段 Go 代码时，你所见即所得，几乎没有隐藏的控制流或隐式的行为。

这种对简单的极致追求，甚至延伸到了对标准库的设计上。为什么 Go 核心不内置一个 Set 类型？有评论认为，一旦官方内置，社区就会停止对这个问题的探索。而现在，虽然生态中可能有 50 种不兼容的 Set 实现，但这恰恰是生态系统该做的事情。语言核心应该保持绝对的稳定和精简，将多样性留给生态去繁荣。

“新移民”的期望：把这里也建成我的家乡

而来自 Java/Python 等生态的“新移民”，则带来了完全不同的期望。他们习惯了 Spring Boot 那种由注解驱动的、“魔法般”的依赖注入；习惯了 Python 丰富的原生数据结构和强大的表达力。他们认为这些特性是“生产力”的体现，是“现代语言的标配”。

于是，我们看到了各种“水土不服”的现象：

• 过度封装：试图用 Java 风格的仓储模式（Repository Pattern）、服务层（Service Layer）去封装 Go database/sql 这样简单直接的库，引入了不必要的复杂性和间接性。
• 依赖泛滥：为了实现一个简单的功能，引入一个庞大的框架或多个第三方库，而忽略了标准库中可能已经存在的、更简单的解决方案。
• 功能请愿：不断地在社区呼吁，希望 Go 能增加他们熟悉的各种语法糖和高级特性。

他们的初衷是好的——他们想“改进”Go，让它变得更“强大”、更“方便”。但问题在于，他们试图在 Go 这片追求极简主义的土地上，复刻他们熟悉的、那个充满了“便利设施”的家园。

这是一场“邪教”崇拜，还是一次理性的坚守？

在激烈的讨论中，一个尖锐的词被提及：“Go 社区有时感觉像个邪教（cult）。”

这个评价虽然刺耳，但也反映了外界对 Go 社区某种“固执”的不解。为什么 Go 开发者会对一些看似“能提升效率”的特性如此抗拒？

我认为，这并非“邪教”式的盲目崇拜，而是一种对设计哲学的深刻理解和理性坚守。

在 Go 之前，很少有主流语言如此旗帜鲜明地将简单性（Simplicity）和明确性（Explicitness）置于表达力（Expressiveness）和简洁性（Conciseness）之上。Go 的巨大成功，恰恰证明了这种看似“反潮流”的哲学，在构建大型、复杂、需要长期维护的系统中，具有无与伦比的价值。

正如发帖者所观察到的：Python 诞生于 1991 年，但著名的“Python 之禅”却是在 8 年后才被总结出来。而 Go，从诞生的第一天起，就带着极其强烈的哲学印记。它的设计者们，是在看尽了 C++ 等语言复杂性带来的痛苦后，才决心开辟一条返璞归真之路。

我们坚守的，不是某个具体的语法，而是这种让无数工程师受益的、来之不易的简单性。

解决方案与未来：我们该何去何从？

面对这场愈演愈烈的“身份危机”，我们该何去何从？我认为，答案不在于简单的“接受”或“拒绝”，而在于划定清晰的边界。

首先，要区分“语言核心”与“生态系统”。

• 语言核心必须保持稳定和简单。 这是 Go 语言的“护城河”，必须被坚定地守护。当然，这不意味着语言一成不变。像泛型（Generics）的引入，就是一个很好的例子。它虽然增加了语言的复杂性，但它解决了一个极其普遍且重要的问题，并且经过了社区长达十年的、极其审慎的讨论和设计。这种演进是可以接受的。但对于那些会引入“魔法”、破坏代码明确性的特性（比如注解驱动的依赖注入），则应该被坚决地挡在语言核心之外。

• 将“欲望”引导到生态系统。 “新移民”们对框架、对“电池”的需求是真实且合理的。但这些，应该由生态系统来满足。我们应该鼓励社区去构建像 Docker、Kubernetes 那样伟大的、遵循 Go 哲学的框架和产品，而不是反过来要求语言本身去迁就框架的设计。让那些喜欢 Spring 的人，去构建一个 Go 版本的、同样优秀的框架，而不是要求 Go 变成 Java。

其次，资深 Gopher 的责任，是“布道”而非“争吵”。

作为社区的“原住民”，我们的责任不仅仅是对那些可能破坏 Go 哲学的建议说“不”，更重要的是，要耐心地、清晰地向新 Gopher 们解释“为什么不”。

我们需要去传承 Go 的设计哲学，分享那些关于“少即是多”的深刻见解，讲述那些因为过度复杂而导致项目失败的“战壕故事”。这比单纯地争论某一个具体特性，对社区的健康发展更为重要。

小结

Go 语言的流行，是其简单哲学的胜利。而这场“身份危机”，正是这场胜利带来的“甜蜜的烦恼”。

我们欢迎所有“新移民”的到来，他们带来了新的活力和视角。但同时，我们也必须清醒地认识到，Go之所以成为Go，正是因为它没有成为其他任何一种语言。

守护 Go 的灵魂，不是要将它变成一座博物馆，而是要确保它在未来的演进中，不会迷失自己的身份。因为这份来之不易的简单，正是它赠予我们所有工程师，最宝贵的礼物。

资料链接：https://www.reddit.com/r/golang/comments/1mktjem/im_experiencing_a_high_pressure_from_new_go/

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

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

本文永久链接 – https://tonybai.com/2025/08/11/why-go-not-embrace-iouring

大家好，我是Tony Bai。

在 Linux I/O 的世界里，io_uring 如同划破夜空的流星，被誉为“终极接口”。它承诺以无与伦比的效率，为数据密集型应用带来革命性的性能提升。正如高性能数据库 ScyllaDB 在其官方博文中所展示的，io_uring 能够将系统性能推向新的高峰。

然而，一个令人费解的问题摆在了所有 Go 开发者面前：作为云原生infra和并发编程的标杆，Go 语言为何对这颗唾手可得的“性能银弹”表现得如此审慎，甚至迟迟未能将其拥抱入标准库的怀抱？一场在 Go 官方仓库持续了五年之久的 Issue 讨论（#31908），为我们揭开了这层神秘的面纱。这并非简单的技术取舍，而是 Go 在其设计哲学、工程现实与安全红线之间进行反复权衡的结果。本文将深入这场讨论，为您揭秘阻碍 io_uring 在 Go 中落地的三大核心困境。

io_uring：一场 I/O 模型的革命

要理解这场争论，我们首先需要明白 io_uring 究竟是什么，以及它为何具有革命性。

在 io_uring 出现之前，Linux 上最高效的 I/O 模型是 epoll。epoll 采用的是一种“拉（pull）”模型：应用程序通过一次 epoll_wait 系统调用来询问内核：“有我关心的文件描述符准备好进行 I/O 了吗？”。内核响应后，应用程序需要再为每个就绪的描述符分别发起 read 或 write 系统调用。这意味着，处理 N 个 I/O 事件至少需要 N+1 次系统调用。

而 io_uring 则彻底改变了游戏规则。它在内核与用户空间之间建立了两个共享内存环形缓冲区：提交队列（Submission Queue, SQ）和完成队列（Completion Queue, CQ）。

其工作流程如下：

1. 提交请求: 应用程序将一个或多个 I/O 请求（如读、写、连接等）作为条目（SQE）放入提交队列中。这仅仅是内存操作，几乎没有开销。
2. 通知内核: 应用通过一次 io_uring_enter 系统调用，通知内核“请处理队列中的所有请求”。在特定模式（SQPOLL）下，这个系统调用甚至可以被省略。
3. 内核处理: 内核从提交队列中批量取走所有请求，并异步地执行它们。
4. 返回结果: 内核将每个操作的结果作为一个条目（CQE）放入完成队列。这同样只是内存操作。
5. 应用收获: 应用程序直接从完成队列中读取结果，无需为每个结果都发起一次系统调用。

这种模式的优势是颠覆性的：它将 N+1 次系统调用压缩为 1 次甚至 0 次，极大地降低了上下文切换的开销，并且首次为 Linux 带来了真正意义上的、无需 O_DIRECT 标志的异步文件 I/O。

最初的希望：一剂治愈 Go I/O“顽疾”的良药

讨论伊始，Go 社区对 io_uring 寄予厚望，期待它能一举解决 Go 在 I/O 领域的两大历史痛点：

1. 真正的异步文件 I/O： Go 的网络 I/O 基于 epoll 实现了非阻塞，但文件 I/O 本质上是阻塞的。为了避免阻塞系统线程，Go 运行时不得不维护一个线程池来处理文件操作。正如社区所期待的，io_uring 最大的吸引力在于“移除对文件 I/O 线程池的需求”，让文件 I/O 也能享受与网络 I/O 同等的高效与优雅。
2. 极致的网络性能： 对于高并发服务器，io_uring 通过将多个 read/write 操作打包成一次系统调用，能显著降低内核态与用户态切换的开销，这在“熔断”和“幽灵”漏洞导致 syscall 成本飙升的后时代尤为重要。

然而，Go 核心团队很快就为这股热情泼上了一盆“冷水”。

核心困境一：运行时模型的“哲学冲突”

这是阻碍 io_uring 集成最根本、最核心的障碍。Go 的成功很大程度上归功于其简洁的并发模型——goroutine，以及对开发者完全透明的调度机制。但 io_uring 的工作模式，与 Go 运行时的核心哲学存在着深刻的冲突。

冲突的焦点在于“透明性”。Ian Lance Taylor 多次强调，问题不在于 io_uring 能否在 Go 中使用，而在于能否“透明地”将其融入现有的 os 和 net 包，而不破坏 Go 开发者早已习惯的 API 和心智模型。

io_uring 的性能优势源于批处理。但 Go 的标准库 API，如 net.Conn.Read()，是一个独立的、阻塞式的调用。Go 用户习惯于在独立的 goroutine 中处理独立的连接。如何将这些分散的独立 I/O 请求，在用户无感知的情况下，“透明地”收集起来，打包成批？这几乎是一个无解的难题。

社区也提出了“每个 P (Processor) 一个 io_uring 环”的设想，但 Ian 指出这会引入极高的复杂性，包括环的争用、空闲 P 的等待与唤醒、P 与 M 切换时的状态管理等。正如一些社区成员所总结的，io_uring 需要一种全新的 I/O 模式，而这与 Go 现有网络模型的模式完全不同。强行“透明”集成，无异于“在不破坏现有 API 的情况下进行不必要的破坏”。

核心困境二：现实世界的“安全红线”

如果说运行时模型的冲突是理论上的“天堑”，那么安全问题则是实践中不可逾越的“红线”。

在 2024 年初，社区成员 jakebailey 抛出了一个重磅消息：出于安全考虑，Docker 默认的 seccomp 配置文件已经禁用了 io_uring。

引用自 Docker 的 commit 信息: “安全专家普遍认为 io_uring 是不安全的。事实上，Google ChromeOS 和 Android 已经关闭了它，所有 Google 生产服务器也关闭了它。”

这个消息对标准库集成而言几乎是致命一击。Go 程序最常见的部署环境就是容器。一个不被“普遍情况”支持的特性，无论其性能多么优越，都难以成为Go运行时和标准库的基石。

核心困境三：追赶一个“移动的目标”

在这场长达五年的讨论中，io_uring 自身也在飞速进化。其作者Jens Axboe 甚至亲自下场，解答了 Go 团队早期的疑虑，例如移除了并发数限制、解决了事件丢失问题等。

但这恰恰揭示了第三重困境：要集成一个仍在高速演进、API 不断变化的底层接口，本身就充满了风险和不确定性。标准库追求的是极致的稳定性和向后兼容性。过早地依赖一个“移动的目标”，可能会带来持续的维护负担和潜在的破坏性变更。对于一个需要支持多个内核版本的语言运行时来说，这种复杂性是难以承受的。

小结：审慎的巨人与退潮的社区热情

io_uring 未能在 Go中落地，并非因为 Go 团队忽视性能，而是其成熟与审慎的体现。三大核心困境层层递进，揭示了其迟迟未能拥抱 io_uring 的深层原因：哲学上的范式冲突、现实中的安全红线、以及工程上的稳定性质疑。

然而，现实比理论更加残酷。在讨论初期，Go 社区曾涌现出一批充满激情的用户层 io_uring 库，如 giouring、go-uring 等，它们是开发者们探索新大陆的先锋。但时至 2025 年，我们观察到一个令人沮丧的趋势：这些曾经的追星项目大多已陷入沉寂，更新寥寥，星光黯淡。

与之形成鲜明对比的是，Rust 的 tokio-uring 库依然保持着旺盛的生命力，社区活跃，迭代频繁。这似乎在暗示，问题不仅在于 io_uring 本身，更在于它与特定语言运行时模型的“契合度”。Go 运行时的 G-P-M 调度模型和它所倡导的编程范式，使得社区自发的集成尝试也步履维艰，最终热情退潮。

这是否意味着 Go 与 io_uring 将永远无缘？或许未来之路有二：一是等待 io_uring 自身和其生态环境（尤其是安全方面）完全成熟；二是 Go 也许可能会引入一套全新的、非透明的、专为高性能 I/O 设计的新标准库包。

在此之前，Go 运行时可能会选择先挖掘 epoll 的全部潜力。这场长达五年的讨论，最终为我们留下了一个深刻的启示：技术的采纳从来不是一场单纯的性能赛跑，它是一场包含了设计哲学、生态现实与工程智慧的复杂博弈。

资料链接：

• https://github.com/golang/go/issues/31908
• https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux/

关注io_uring在Linux kernel内核演进的小伙伴儿们，可以关注io-uring.vger.kernel.org archive mirror这个页面，或io_uring作者Jens Axboe的liburing wiki。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

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