MoreRSS

site iconTonyBai | 白明修改

重复
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

TonyBai | 白明的 RSS 预览

J组!阿根廷开启2026卫冕之旅:梅西,这一次,请尽情享受足球!

2025-12-06 07:40:27

本文永久链接 – https://tonybai.com/2025/12/06/argentina-2026-world-cup-title-defense-messi-enjoy-football

大家好,我是Tony Bai。

四年(其实是三年半)的时光,快得像潘帕斯草原上掠过的风。

仿佛昨天,我们还在多哈的卢塞尔球场,在这个星球上最漫长、最窒息的决赛夜里,陪着那个男人哭,陪着那个男人笑。那一夜,青春圆满,诸神归位。我们终于可以骄傲地在胸前绣上第三颗星。

一转眼,2026美加墨世界杯的脚步近了。当昨夜的抽签结果尘埃落定,看到阿根廷落位 J组,我的心里没有了四年前那种“不成功便成仁”的悲壮,取而代之的,是一份从容与平静。

J组:阿根廷、阿尔及利亚、奥地利、约旦

这是一支上上签吗?也许是。这是一支冠军签吗?只有时间知道。

但对我,对无数阿根廷和梅西的球迷来说,这支签意味着——我们的故事,有了新的续篇。


对手扫描:不轻视,亦不畏惧

先来聊聊这一组的对手。在这个扩军到48支球队的全新赛场上,没有绝对的弱旅,只有未知的挑战。

奥地利:欧洲的硬骨头

这或许是小组赛最大的考验。奥地利队球风硬朗,战术执行力极强,有着典型的欧洲球队纪律性。他们就像一块坚硬的试金石,用来检验卫冕冠军的防线成色再合适不过。和他们的比赛,注定不会轻松,但这正是我们需要的热身强度。

阿尔及利亚:北非之狐

非洲球队在世界杯上从来都是不可忽视的力量。阿尔及利亚技术细腻,身体素质出色。面对这种灵巧与力量兼具的对手,阿根廷需要打起十二分精神,利用我们的控制力和经验去主导比赛。

约旦:亚洲的新兴力量

对于约旦队,我们更多的是陌生。作为亚洲杯的亚军级别球队,他们有着极强的拼劲和韧性。这场比赛,或许是斯卡洛尼演练进攻套路、让马斯坦托诺等年轻小将感受世界杯氛围的最佳舞台。

总体来说: 这是一个“以我为主”的分组。只要潘帕斯雄鹰正常展翅,小组头名出线是底线,也是必须完成的任务。


卫冕魔咒?我们早已看淡

提到世界杯,就绕不开那个令人色变的“卫冕冠军魔咒”。

历史上,能够成功卫冕世界杯的球队凤毛麟角。强如当年的法国、意大利、德国、西班牙,都曾在卫冕之路上折戟沉沙,甚至小组出局。

注:在前22届世界杯里,一共只出现过2次卫冕成功的,分别是1938年法国世界杯,意大利卫冕成功,1962年智利世界杯,巴西卫冕成功。

阿根廷会打破魔咒吗?

说实话,作为一名看了几十年球的老阿根廷粉,我心里反倒没有那么重的包袱。

2014年的亚军以及2022年的那一冠,已经耗尽了我所有的眼泪和祈祷,也填补了心中所有的遗憾。2022年那一冠,是上帝对梅西最好的褒奖,也是对阿根廷足球最好的交代。

这一次,我们不再是背负着沉重十字架的苦行僧,我们是享受比赛的卫冕之王。

如果能卫冕,那是神迹的延续,是再一次的疯狂;如果不能,那也是足球规律的使然,我们依然拥有那颗金色的第三颗星,依然拥有那个最好的里奥·梅西。

这种心态的转变,或许才是阿根廷队最可怕的武器。轻装上阵,往往能爆发出惊人的能量。


梅西:最后一舞,只愿你快乐

2026年,梅西将年近39岁。

我们心里都清楚,这可能是他的最后一届世界杯了。

这一次,我们不再奢求他像2014年那样单骑闯关,也不再苛求他像2022年那样场场Carry。

无论他是首发登场,还是替补奇兵;无论他是踢满全场,还是在场边鼓掌激励队友……只要他还在那里,只要他还穿着那件蓝白球衣,我们的心就是安定的。

他已经是公认的球王,已是GOAT,他不需要再向任何人证明什么。

对于2026,我唯一的期待,就是希望梅西能开心

希望他能享受每一次触球,享受每一次传球,享受在草皮上奔跑的每一秒。希望没有伤病,没有过度的压力,只有足球最纯粹的快乐。

就像他在迈阿密那样,脸上挂着笑容,眼里闪着光。


结语:VAMOS ARGENTINA!

J组的签位已定,新的征程即将开启。

斯卡洛尼的战车再次启动,恩佐、麦卡利斯特、阿尔瓦雷斯这些曾经的小将已经成长为中流砥柱,更加年轻的血液正在涌动。

我们期待胜利,但我们更珍惜相聚。

各位阿迷梅粉们,球衣准备好了吗?啤酒和马黛茶准备好了吗?

让我们一起,陪着阿根廷,陪着梅西,去迎接这场美加墨的足球盛宴。不问终点,只问热爱。

梅西,请尽情享受你的最后一舞吧!

VAMOS ARGENTINA!


留言区聊聊:

2026世界杯,你对阿根廷最大的期待是什么?是再夺一冠,还是仅仅希望看到梅西多踢几场?


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


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

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

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

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

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


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

© 2025, bigwhite. 版权所有.

Go 安全新提案:runtime/secret 能否终结密钥残留的噩梦?

2025-12-05 15:55:14

本文永久链接 – https://tonybai.com/2025/12/05/proposal-runtime-secret

大家好,我是Tony Bai。

“如果你的服务器被攻破,攻击者能否拿到内存中残留的私钥,进而解密过去两年的所有通信记录?”

这是一个让所有安全工程师夜不能寐的问题。为了防止这种情况,现代加密协议(如 TLS 1.3, WireGuard)都强调前向保密 (Forward Secrecy):使用临时的、一次性的密钥,并在使用后立即销毁。

然而,在 Go 语言中,“立即销毁”这个看似简单的动作,却是一个巨大的技术难题。由于垃圾回收 (GC)、堆栈复制、以及缺乏对内存的底层控制,Go 程序很难保证敏感数据被彻底擦除。

针对这一痛点,Go 社区大神 Jason A. Donenfeld(WireGuard作者,ID: zx2c4) 发起了一项长达数年的提案——引入 runtime/secret 包。近日,该提案已进入实现阶段,有望在Go 1.26版本中落地,并彻底改变 Go 处理敏感数据的方式。

img{512x368}

核心痛点:为什么 memset(0) 在 Go 中不够用?

在 C 语言中,我们可以调用 explicit_bzero 来擦除内存。但在 Go 中,情况要复杂得多:

  1. 隐式拷贝:Go 的切片操作、函数传参、甚至简单的赋值,都可能在堆或栈上留下数据的副本。你擦除了一份,却可能漏掉了其他三份。
  2. GC 的不确定性:垃圾回收器何时运行?被回收的内存是否会被立即归零?这些都是未知的。
  3. 堆栈扩容:当 goroutine 栈空间不足时,Go 运行时会分配一个更大的新栈,并将旧栈的数据拷贝过去。旧栈中的敏感数据就此残留,且不再被追踪。
  4. 编译器优化:简单的“写入零值”操作可能会被编译器视为“死代码”而优化掉。

正如 WireGuard 的 Go 实现中遇到的尴尬局面:为了擦除一个 AEAD 对象中的密钥,开发者不得不使用反射 (Reflection) 这种“旁门左道”来重置其内部字段,既不优雅也不可靠。

提案及演进:从 SetZeroOnGC 到 secret.Do

这项提案的讨论过程,简直是一部 Go 运行时机制的“解剖学教程”。

早期尝试:SetZeroOnGC

最初的设想是让用户标记某个对象,告诉 GC 在回收它时必须将其内存归零。

但这无法解决栈上数据的残留问题,也无法处理那些在函数调用过程中产生的临时副本。

中期探索:自定义分配器与 SetFinalizer

有人提议使用 memguard 等库,通过 mmap 分配不受 GC 管理的内存。

但这需要重写所有加密库的 API,使其接受自定义分配器,工程量巨大且不兼容现有生态。

最终方案:runtime/secret 包

经过反复权衡,Go 团队和社区最终汇聚到了一个基于动态作用域的解决方案上。提案的核心 API 极其简洁:

package secret

// Do 执行函数 f。
// 当 secret.Do 返回时:
//   - 清除函数 f 执行期间创建的所有栈帧(stack frames)。
//   - 清除所有可能包含secret的寄存器。
//   - 在secret模式下栈增长时,清除旧的栈。
//   - secret模式下,在 f 执行期间分配的所有堆对象,会被标记为“敏感”,并在 GC 回收时被安全擦除。
//   - 如果函数出现panic,则将该panic提升为来自 secret.Do 的异常。这会从回溯中移除有关secret函数的任何信息。

func Do(f func())

这个设计不仅解决了堆内存的问题,更关键的是,它提供了一个“安全沙箱”。在这个沙箱内,你可以放心地进行加密计算,Go 运行时会负责清理你在栈上留下的所有痕迹。

使用场景:WireGuard 与 TLS

想象一下 WireGuard 的握手过程:

func handleHandshake() {
    secret.Do(func() {
        // 1. 生成临时私钥 (在栈上或堆上)
        ephemeralPrivateKey := generateKey()

        // 2. 计算共享密钥 (产生大量中间计算结果)
        sharedKey := computeSharedKey(ephemeralPrivateKey, peerPublicKey)

        // 3. 使用共享密钥进行加密操作
        // ...

        // 函数返回时:
        // - ephemeralPrivateKey 所在的栈帧被立即擦除
        // - sharedKey 等堆对象被标记,GC 回收时自动擦除
    })
}

开发者不需要手动追踪每一个变量,也不需要担心 copy 操作泄露数据。只要在 secret.Do 的闭包内,一切都是安全的。

深水区的挑战:信号、GC 与汇编

虽然 API 设计看似完美,但实现起来却是困难重重。今年的最新讨论揭示了几个令人头秃的底层挑战:

  1. 信号处理 (Signals):如果程序在 secret.Do 执行期间收到系统信号,CPU 寄存器中的敏感数据会被操作系统保存到“信号栈”中。这相当于泄露了数据!

  2. 垃圾回收器 (GC):GC 在扫描内存时,可能会将敏感指针加载到自己的寄存器或栈中。如何确保 GC 线程本身不泄露数据?这是一个极其棘手的工程问题。

  3. 汇编代码:Go 的加密库大量使用了汇编优化。如何确保这些汇编代码在使用完寄存器后正确地将其清零?

当然,目前该提案的开发者 Daniel Morsing 已经逐个克服了上述挑战,比如针对信号处理的问题,他提出了一种巧妙的“影子栈”方案,试图在信号处理返回前拦截并擦除这些数据。Daniel Morsing针对该提案的cl 704615 近期已经被merge,有望在Go 1.26落地。

不过目前,该secret包仅在linux for arm64 and amd64上有实现。

小结:安全是场持久战

runtime/secret 提案的推进,标志着 Go 语言在系统级安全领域迈出了重要一步。它不仅回应了高安全等级应用(如金融、国防)的需求,也体现了 Go 团队在面对复杂底层问题时的务实与坚持。

虽然已经被merge,但历史经验告诉我们,距离该功能成熟可能还有一段路要走,后续仍在会有一些问题和实现细节需要解决,但它所传达的信号是明确的:Go 正在成为编写安全基础设施的首选语言之一。

对于我们普通开发者而言,虽然我们未必会在业务代码中直接 import 这个包(runtime/secret),但关注这个提案的进展,不仅能让我们见证 Go 语言如何填补安全拼图中至关重要的一角,更能让我们在“围观”其解决信号处理、GC 交互等硬核挑战的过程中,完成一次对 Go 运行时底层机制的深度认知升级。当这一基础设施最终就位时,我们将能以更强的信心,站在更坚固的安全基石之上构建应用。

资料链接:https://github.com/golang/go/issues/21865


聊聊你眼中的 Go 安全基石

runtime/secret 提案的推进,为 Go 在高安全等级场景的应用补上了一块关键的拼图。你在日常的 Go 开发中,是否也曾为如何安全地处理密钥、Token 等敏感数据而感到困扰?除了内存残留问题,你认为 Go 在安全方面还有哪些亟待完善的“深水区”?

或者,你对 secret.Do 这种通过“安全沙箱”来解决问题的方式有何看法?它是否是你心中理想的解决方案?

欢迎在评论区分享你的实战经验、安全痛点,或对 Go 语言安全生态的任何期待与建议! 让我们一起探讨,共同构建一个更安全的 Go 世界。

如果这篇文章让你对 Go 的底层安全有了新的认识,别忘了点个【赞】和【在看】,并分享给更多关注 Go 安全的同伴!


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

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

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

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

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


想系统学习Go,构建扎实的知识体系?

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏,内容全面升级,同步至Go 1.24。首发期有专属五折优惠,不到40元即可入手,扫码即可拥有这本300页的Go语言入门宝典,即刻开启你的Go语言高效学习之旅!


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

© 2025, bigwhite. 版权所有.

Anthropic 内部报告:程序员的“死”与“生”,效率暴增 50% 的残酷启示

2025-12-05 08:16:01

本文永久链接 – https://tonybai.com/2025/12/05/how-ai-is-transforming-work-at-anthropic

大家好,我是Tony Bai。

当我们还在争论 AI 编程是否是“玩具”时,Anthropic 已经把镜头对准了自己。

2025 年 8 月,这家打造了 Claude 的顶尖 AI 公司,对自己内部的 132 名工程师和研究员进行了一次深度“体检”。他们分析了 20 万条 Claude Code(Anthropic 打造的、并同时也在内部使用的 AI 编程 CLI 工具)的使用记录,并进行了深度的定性访谈。

这份刚刚发布的调研报告,揭示了一个既令人兴奋又令人胆寒的真相:在 AI 原生工作流的加持下,工程师的生产力暴增了 50%,但旧时代的“程序员”正在死去,一种全新的职业物种正在诞生。

在我看来,这既是一份内部效率调查报告,更是一份关于软件工程师职业命运的“生死簿”。


“生”的狂欢:效率暴增 50% 后的质变

数据是惊人的,甚至可以说是具有颠覆性的。

与一年前相比,Anthropic 工程师使用 Claude 的频率翻了一倍,自我报告的生产力提升从 20% 飙升到了 50%。在极端的“超级用户”(Power Users,占总数 14%)中,这一数字甚至超过了 100%。

但这种提升并非意味着大家“闲下来”了。报告发现了一个反直觉的现象:在 AI 的辅助下,工程师们花在每个任务上的时间变少了,但产出的总工作量却大幅增加了。

这不仅仅是效率的量变,更是工作内容的质变:

  • 新功能的爆发:在 Claude Code 的帮助下,工程师用于“实现新功能”的时间占比从六个月前的 14% 激增至 37%(如下图)。AI 不再只是写样板代码的助手,而是直接参与核心构建的主力。

  • 消灭“千纸鹤”:数据显示,8.6% 的 Claude Code 任务是在处理那些长期存在、令人烦恼但优先级不高的“小毛病”。这包括重构糟糕的代码结构、编写缺失的测试、或是构建一个小工具来优化流程。正如一位工程师所言:“通过降低‘激活能量’,AI 让我不再拖延,愿意去解决那些以前觉得‘不值得动手’的麻烦事。”
  • “第 27%”的创新:员工估计,27% 的 AI 辅助工作是“如果没有 AI 就根本不会做”的。这包括构建交互式数据仪表盘、进行更广泛的探索性测试,或者像一位研究员那样——运行一个拥有“百万马力”的 Claude 实例来测试不同的想法。

AI 并没有让工程师“摸鱼”,而是赋予了他们“三头六臂”,让他们在同样的时间里,触达了以前无法企及的广度和深度。


边界的消亡:人人都是全栈工程师

报告中最令人兴奋——也最让传统岗位感到“危机”——的发现之一,是 AI 开发工作流 正在打破工程师的技能边界。一种“全能化” (Full-stackization) 的趋势正在形成,专业分工的护城河正在被填平。

  • 后端写前端:一位后端工程师描述了他如何通过提示词(Prompting)构建了一个复杂的 UI:“它做得比我好多了。如果是以前,我绝对做不到,更不可能按时完成。设计师问我‘这是你做的?’我说‘不,是 Claude 做的,我只是负责提示。’”
  • 安全做开发:安全团队利用 Claude Code 快速理解陌生的代码库,分析不同模块的安全隐患,其使用场景中有 48.9% 是为了“代码理解”。
  • 非技术人员写代码:产品经理和研究员开始自己动手修复 Bug、编写数据分析脚本,填补了技术与业务之间的沟壑。

这种变化意味着,软件工程师将不再被特定的语言或框架(如“Go 专家”或“React 大师”)所定义,而是被解决问题的能力所定义。在 AI 原生工作流中,只要有想法,技术栈不再是护城河,而是可以随意调用的工具箱。


信任的进化:从“验证”到“导航”

随着 Claude Code 及其背后模型的进化(从 Sonnet 到 Opus),工程师们对 AI 的使用方式经历了从“小心翼翼”到“深度协同”的转变。

  • Agentic(自主智能体化)能力的飞跃:六个月前,Claude Code 平均只能连续执行 10 个操作;现在,它可以自主完成约 21.2 个连续的工具调用(如编辑文件、运行测试、修复错误),期间无需人类干预。
  • 从“谷歌地图”到“自动驾驶”:一位工程师用“谷歌地图”来比喻这种信任的演变。起初,我们只在熟悉的路段用导航;后来,即使导航给出了一条陌生的路线,我们也愿意相信它是最优解。
  • 信任但验证 (Trust but Verify):但这并不意味着盲从。报告指出,工程师们发展出了一套成熟的AI 协作策略:对于低风险、易验证的任务(如生成测试数据),直接放手;对于高风险、核心逻辑的任务,则保持高度的“人机协同”。

“冷启动”问题成为了新的瓶颈。一位工程师坦言:“如果我有关于代码库的大量隐性知识,而 Claude 没有,我宁愿自己写,也不想花时间去写完美的 Prompt。” 这也暗示了在 AI 开发工作流中,上下文管理 (Context Management) 将成为一项核心技能。


“死”的阴影:残酷的技能萎缩与监督悖论

然而,硬币的另一面是深深的焦虑。报告极其诚实地记录了工程师们面临的“残酷”现实——旧的生存法则正在失效。

1. “监督悖论”

这是报告中最深刻、最令人不安的洞见之一。高效使用 Claude 需要监督,而监督 Claude 需要高超的编码技能。“如果我不再亲自写代码,不再通过痛苦的调试来建立对系统的直觉,我的技能会萎缩吗?” 如果技能萎缩了,未来谁还有能力去评估 AI 写出的代码是好是坏?

一位资深工程师坦言:“我现在主要用 AI 做我已经知道答案的事情。这种直觉是我通过‘硬核模式’积累的。如果我是现在的初级工程师,我不知道该如何建立这种直觉。”

2. 社交的“原子化”

Claude 成为了“第一咨询对象”。原本需要问同事的问题,现在 80-90% 都先问 AI。这虽然减少了对他人的打扰,但也切断了隐性的知识传递。初级工程师失去了向资深工程师提问的机会,团队的凝聚力面临挑战。一位 Tech Lead 感叹:“初级员工不再带着问题来找我了,这让我感到失落。”

3. “把自己淘汰”的担忧

“我觉得我每天上班都在致力于让自己失业。” 这种情绪在访谈中并不罕见。虽然短期内大家对生产力的提升感到兴奋,但对于长期——当 AI 真的能由端到端地完成所有工作时——人类工程师的位置在哪里?

一位工程师的比喻令人深思:“也许我们正在从编写代码,转向编写英语作为一种编程语言。未来的核心技能,是擅长让 AI 干活。”


小结:在“副驾驶”与“自动驾驶”之间

Anthropic 的这份报告,向我们展示了一个正在加速到来的未来:软件工程正在从“手工艺”转向“工业化管理”。

旧时代的“码农”——那些仅仅通过记忆语法和 API 来堆砌代码的人——正在不可避免地走向消亡

而新时代的工程师正在重生。他们更像是一位指挥家,挥舞着 Claude Code 这样的指挥棒,构建高效的 AI 开发工作流,调动着成千上万的虚拟算力,去构建前所未有的宏大系统。

“残酷”的真相在于:技术不会淘汰工程师,但“掌握 AI 开发工作流”的工程师将淘汰那些还在徒手搬砖的人。

拒绝 AI 的人,注定无法成为这场变革的指挥家。

要查阅这份报告的更多详情,请访问 Anthropic 的研究页面


你感受到这种变化了吗?

看了Anthropic的报告,你是感到兴奋还是焦虑?在你的日常工作中,AI是你的“副驾驶”,还是已经开始接管方向盘了?你担心中断“硬核模式”训练会导致技能萎缩吗?

欢迎在评论区分享你的真实感受和思考!


** 想要掌控这套未来的“指挥棒”?**

Anthropic 的工程师们已经向我们证明:效率提升 50% 只是起步。在这个“死”与“生”的转折点,你准备好进化了吗?

你是否也想打破技能边界,从后端迈向全栈,甚至更多?
你是否想知道如何构建自己的 Context,解决 AI 的“冷启动”问题,规避“监督悖论”?

我精心打造的极客时间专栏《AI 原生开发工作流实战》,正是为你准备的“生存与进化手册”。

别让未来把你抛下。扫描下方二维码,立刻开启你的 AI 原生开发之旅!


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

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

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

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

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


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

© 2025, bigwhite. 版权所有.

MinIO 开源版突发“安乐死”:维护模式开启,社区愤怒,你的数据还安全吗?

2025-12-04 17:40:44

本文永久链接 – https://tonybai.com/2025/12/04/minio-enter-maintenance-mode

大家好,我是Tony Bai。

“这个项目目前处于维护状态,不接受新的更改。”

近日,GitHub 上拥有近 60k Star、Go 语言生态中最著名的开源对象存储项目——MinIO,悄然修改了其 README。这一行看似平淡的声明,标志着 MinIO 开源版实际上已经被宣判了“死刑”。

曾经,MinIO 是自建 S3 兼容存储的首选,是开源界的宠儿。如今,它转身拥抱了企业级市场和 AI 浪潮,留下了一脸错愕的社区用户和无数依赖它的开源项目。这究竟是一场无奈的求生,还是一次蓄谋已久的“收割”?

突如其来的“维护模式”

MinIO 官方在没有任何预警的情况下,将其开源仓库置于“维护模式”。这意味着:

  • 功能冻结:不再接受任何新功能或改进。
  • 社区关门:不再接受 Pull Request,现有的 Issue 和 PR 也不会被积极审查。
  • 安全补丁随缘:关键的安全修复“可能”会根据具体情况进行评估,不再有保证。

官方建议很明确:“对于企业支持和积极维护的版本,请参阅MinIO AIStor。”,而AIStor则是MinIO的企业版对象存储产品。

这一举动在 Hacker News 上引发了轩然大波。用户感到被背叛,一位评论者愤怒地写道:“太恶心了。构建一个产品,通过开源获得动力,等你做完了就完全抛弃它。我为曾经推广这个项目感到羞耻。”

为何“背叛”?—— 商业化的必然与 AI 的诱惑

MinIO 的转向并非无迹可寻。从更换为更严格的 AGPL 协议,到此次事实上的闭源,其背后的逻辑清晰而冷酷:

开源无法变现的困境

MinIO 作为一个高性能、单二进制文件的存储服务,太容易“被集成”了。云厂商、集成商可以轻松地将其打包进自己的产品中获利,而 MinIO 公司却难以从中分一杯羹。AGPL 协议虽然意在限制云厂商的“白嫖”,但也未能从根本上解决其商业化难题。

AI 浪潮的巨大诱惑

MinIO 的新产品名为 AIStor。这不仅仅是一个改名,更是一次战略转型。在 AI 时代,数据存储是基础设施的核心。MinIO 试图通过重新包装,将自己定位为 AI 基础设施的关键组件,从而向更有付费能力的企业客户(尤其是 AI 公司)靠拢。

正如一位 HN 用户指出的:“他们在上一轮融资中估值 10 亿美元,要想成功退出,必须有深口袋的买家(如 Nvidia, Dell 等)。现在的开源版本只会拖累他们的财报。”

社区的反击与法律迷局

MinIO 的做法也引发了法律层面的争议。

  • 贡献者的权利:MinIO 曾要求贡献者签署 CLA(贡献者许可协议)。这意味着 MinIO 公司拥有代码的版权,他们确实有权改变许可证或停止开源。
  • AGPL 的约束:但对于那些没有签署 CLA 的早期贡献者,或者包含在代码库中的第三方 AGPL 代码,MinIO 是否有权单方面“私有化”?这是一个复杂的法律问题。

更有趣的是,MinIO 过去曾因 AGPL 许可问题积极“维权”,甚至公开指责其他公司违反协议。如今,它自己却试图摆脱开源的束缚,这种双重标准让社区感到讽刺。

历史的镜像 —— Redis 与 Valkey 的启示

MinIO 的剧变,让人不由得想起了 2024 年初震动开源界的另一场“地震”——Redis 修改开源协议事件

当时,Redis Inc. 宣布不再遵循开源定义,转而采用限制性更强的 SSPL 协议。这一举动激怒了整个社区和云厂商,Linux 基金会迅速集结了 AWS、Google、Oracle 等巨头,基于 Redis 旧版本 fork 出了 Valkey。如今,Valkey 已经展现出取代 Redis 的蓬勃生命力。

MinIO 与 Redis 的异同:

  • 相同点:两者都面临“云厂商困境”。AWS 直接拿 Redis 做 ElastiCache,拿 MinIO 做兼容 S3 的服务,却无需向原厂付费。原厂为了生存,不得不通过协议(AGPL/SSPL)或停止维护来“筑墙”。
  • 不同点:Redis 选择了“掀桌子”(改协议),引发了激烈的对抗和即时的 Fork(Valkey);而 MinIO 选择了“冷处理”(维护模式),这更像是一种温水煮青蛙式的告别。

MinIO 会迎来它的“Valkey 时刻”吗?

目前来看,难。对象存储的复杂度和维护成本远高于内存缓存,且市场上已经存在成熟的替代品(如 SeaweedFS, Ceph, Garage)。MinIO 社区或许不会像 Redis 那样迅速集结出一个统一的 Fork,而是会走向分裂和迁徙

对于开发者而言,Redis 和 MinIO 的连续“暴雷”是一个明确的信号:在基础设施选型时,除了关注技术指标,更要评估其背后的治理模式。由单一商业公司绝对控制的“开源”项目,始终悬着一把达摩克利斯之剑。

自救指南 —— 寻找 MinIO 的替代品

对于现有的 MinIO 用户来说,现在是时候寻找备胎了。社区推荐了几个值得关注的替代方案:

SeaweedFS (Go)

  • 特点:基于 Haystack 论文实现,擅长处理海量小文件,自带 File 和 S3 接口。
  • 适用场景:需要高性能小文件存储的场景。
  • 评价:功能丰富,甚至有点“过度”,但性能强悍。

Ceph (C++)

  • 特点:存储界的瑞士军刀,功能极其强大,但也极其复杂。
  • 适用场景:大规模、生产级、需要块存储和文件存储的场景。
  • 评价:如果你有运维团队,Ceph 是永远不会错的选择。

Versity Gateway (Go)

  • 特点:基于文件的 S3 网关,可以在开发测试环境作为 MinIO 的直接替代品,后端直接对接文件系统。

RustFS (Rust)

  • 特点:野心勃勃的新晋选手,试图在性能和易用性上直接对标甚至超越 MinIO。
  • 适用场景:极客尝鲜、非生产环境的测试与评估。
  • 评价:社区评价两极分化。一方面,它展现了强大的潜力;另一方面,用户反馈其目前稳定性欠佳,且项目要求签署 CLA(贡献者许可协议),这让不少刚被 MinIO 伤过心的开发者担心它未来会重演“养肥再杀”的剧本。“潜力巨大,但需谨慎观望。”

Garage (Rust)

  • 特点:轻量级、自包含、专注于在异构硬件和地理分布的网络上运行。
  • 适用场景:自托管、家庭实验室、中小规模集群。
  • 评价:“非常稳固,简单可靠,没有风险投资背景。”

小结:开源的尽头是商业,还是背叛?

MinIO 的故事,是开源软件商业化困境的又一个注脚。它提醒我们:

  • 没有免费的午餐:由 VC 支持的开源项目,最终都要面临盈利的压力。当增长遇到瓶颈,社区往往是被牺牲的第一个对象。
  • 选择开源项目需谨慎:除了代码质量,项目的治理结构、CLA 协议、背后的商业模式,都是选型时必须考虑的风险因素。

MinIO 虽已“离去”,但开源精神不死。也许下一个更好的 MinIO,正在某个 GitHub 的角落里悄然生长。

资料链接:https://news.ycombinator.com/item?id=46136023


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


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

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

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

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

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


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

© 2025, bigwhite. 版权所有.

别盲目梭哈 Agentic AI!先看清“确定性”的崩塌与“概率性”重建

2025-12-04 08:17:12

本文永久链接 – https://tonybai.com/2025/12/04/thoughts-before-all-in-agentic-ai

大家好,我是Tony Bai。

如果你在 IT 行业待得够久,最近可能会有一种强烈的“既视感”。

现在的 AI 热潮,像极了当年的移动互联网元年。VC 们兴奋地喊着“所有行业都值得用 AI 重做一遍”。于是我们看到了 AI 版的 Office、AI 版的客服、AI 版的 IDE。表面上看,这确实是历史周期的又一次轮回:新平台出现,旧应用迁移

但作为在一线写代码的工程师或架构师,你可能隐约感觉到一种前所未有的“失控感”

以前我们将业务从 PC 迁移到手机,底层逻辑是没变的:输入 A,经过代码 B,必然得到输出 C。这是一个确定性(Deterministic)的世界,我们是构建规则的“上帝”。

但当我们试图把业务迁移到 LLM(大语言模型)上时,地基塌了。同样的 Prompt,今天的结果可能和明天不一样;模型一换,一切全乱;模型会一本正经地胡说八道;原本严丝合缝的逻辑代码,变成了一场概率的游戏。

别被表象骗了。这不仅仅是技术栈的升级,这是计算机科学底层“物理法则”的改变。

我们正在从牛顿力学的“确定性时代”,跨入量子力学的“概率性时代”。在梭哈 Agentic AI(自主智能体)之前,如果看不清这两者的断裂,你的系统注定会崩塌。

img{512x368}


两个世界的对撞:计算器 vs. 实习生

为了讲清楚这个第一性原理的差异,我们不妨打个比方。

经典应用:永远正确的“计算器”

过去几十年我们构建的软件(ERP、SaaS、OS),本质上都是一台极其精密的“超级计算器”

  • 第一性原理: 布尔逻辑(Boolean Logic)。0 就是 0,1 就是 1。
  • 交互模式: 结构化指令。你必须准确点击菜单、输入 SQL,稍微错一个字符,系统就报错(Crash)。
  • 优势: 精准、可控、100% 可复现。
  • 缺陷: 它没有任何“理解力”。它不知道你为什么要算这个数,它只是机械执行。

AI 原生应用:聪明但会撒谎的“实习生”

而以 LLM 为核心的 AI Agent,本质上是一个名校毕业的“聪明实习生”

  • 第一性原理: 概率与高维向量(Probability & Vector Space)。它不是在“检索”答案,而是在“预测”下一个字出现的概率。
  • 交互模式: 自然语言意图。你说“帮我搞定那个客户”,它去猜这意味着什么。
  • 优势: 泛化能力强,能理解模糊意图,有创造力。
  • 缺陷: 不可控。 它会“幻觉”(不懂装懂),会跑偏。它的错误不是 Bug,而是概率模型的 Feature(特性)。

现在的痛苦源于什么?

源于我们试图用管理“计算器”的方法(单元测试、严格断言、精确匹配)去管理“实习生”。这注定是徒劳的。


幻觉不是 Bug,是创造力的代价

很多老板问:“能不能让 AI 像数据库一样准确,永远别出错?”

从第一性原理看,不能。

生成式 AI 的核心能力是“联想”和“生成”。如果你把它的温度(Temperature)降到绝对零度,强行让它变得完全确定,它就失去了智能,退化成了一个极其昂贵的搜索引擎。

“确定性”和“创造力”是一对互斥的变量。

  • 银行账务系统需要 100% 的确定性,所以它绝对不能用 LLM 来做核心计算(你不能让 AI 预测你的余额)。
  • 创意写作、咨询建议、模糊检索需要的是发散性,这里是 AI 的主场。

所以,AI 原生应用不可能替代所有经典应用。世界将分裂为两半:

  1. 确定性堡垒: 交易、工控、底层架构。(经典代码统治)
  2. 概率性旷野: 内容生成、意图理解、决策辅助。(AI 模型统治)

那么,介于两者之间的广阔中间地带(大多数企业软件)该怎么办?


Agentic AI:在混乱中重建秩序的架构

这正是 AI Agent(智能体) 诞生的意义。

Agent 不是简单的 Chatbot,它是一种架构模式。它的核心使命是:用逻辑框架去约束概率模型,让“不确定”的大脑安全地操作“确定”的工具。

我们可以把未来的软件架构想象成一个“倒三明治”:

  1. 上层(用户意图): 模糊、多变、自然语言。(用户说:“给张总发个报价单”)
  2. 中层(Agent 大脑): 概率性核心。 负责拆解任务、规划路径、选择工具。(AI 思考:“张总是谁?报价单格式是什么?我要调用哪个 API?”)
  3. 底层(Tools/APIs): 确定性基石。 数据库、CRM、计算器。(执行:SELECT * FROM users WHERE name=’Zhang’,SEND_EMAIL(…))

这就是“实习生 + 计算器”模式:

你指挥实习生(AI),实习生去按计算器(经典 App)。

在这个架构中,经典应用/服务并没有死,它们退隐到了后台,变成了 Agent 手中的 Tools



程序员的进化:从“编写逻辑”到“管理概率”

面对这种架构的崩塌与重建,我们这一代程序员的技能树需要重构。

1. 别扔掉你的 SQL 和 Go

Agent 再聪明,也需要“手脚”。高质量的、原子化的、幂等的 API 变得比以往任何时候都重要。你需要把复杂的业务逻辑封装成 AI 能看懂的 Tool Description(工具描述)。经典后端开发依然是地基。

2. 学习“概率工程学” (Probability Engineering)

你不再是写 if-else 的人,你是 Agent 的老师。

  • Prompt Engineering: 编写清晰的岗位说明书。
  • RAG (检索增强): 给实习生提供准确的参考书,减少幻觉。
  • Eval (评估): 建立一套评价体系,去测试这个“实习生”在 1000 次任务中的表现是否达标(而不是纠结于某一次的对错)。

3. 学会设计“护栏”

既然实习生不可控,你就需要设计审查机制。在 Agent 输出结果给用户之前,加一层确定性的校验代码(比如:检查生成的 SQL 是否包含 DELETE 语句,检查生成的金额是否超过上限)。

小结

回到最初的话题。我们并不是在简单的“重做”软件,我们是在培育一个新的物种。

以前,我们强迫人去适应机器,学习机器的菜单和逻辑;

现在,机器终于开始适应人,试图理解我们的模糊与混沌。

虽然这个过程充满了不确定性,充满了“幻觉”和挑战,但这正是进化的代价。梭哈 Agentic AI 之前,请先接受这个世界的随机性,然后用你精湛的工程能力,给它套上逻辑的缰绳。


聊聊你的“人机协作”体验

“确定性”与“概率性”的碰撞,正在重塑我们的代码世界。在你的开发实践中,是否也遇到过因 LLM 的“不确定性”而抓狂的时刻?你是如何给这位“聪明实习生”设计“护栏”的?对于这种全新的“概率性”编程范式,你是感到兴奋还是焦虑?

欢迎在评论区分享你的思考与实战经验! 让我们一起探索这个新时代的生存法则。


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


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

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

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

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

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


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

© 2025, bigwhite. 版权所有.

Go 2025云原生与可观测年度报告:底层性能革新与生态固防

2025-12-03 08:09:11

本文永久链接 – https://tonybai.com/2025/12/03/go-2025-cloud-native-observability-report

大家好,我是Tony Bai。

2025年,对于 Go 语言和云原生生态来说,是充满挑战与变革的一年。

凭借务实的并发模型、极快的编译速度和极简的部署体验,Go 语言在过去十年间毫无争议地坐稳了现代云原生基础设施的“铁王座”。从 KubernetesDocker,从 Prometheusetcd,CNCF 生态中那些最耀眼的明星项目,几乎都流淌着 Go 的血液。

但技术世界没有永远的王座。2025年,面对日益复杂的云原生挑战——如容器资源的极致限制、大规模并发状态管理,以及来自 Rust 等追求极致性能的新生代语言的“围剿”——Go 语言并非高枕无忧。

面对挑战,Go 在 2025 年交出了一份怎样的答卷?它是如何通过 Go 1.25 的底层性能革新、Kubernetes 的架构演进以及 OpenTelemetry 的生态防御来巩固壁垒的?

本文将带你全景式复盘 Go 语言在 2025 年的硬核反击战。


底层突破:Go 1.25 为云原生带来的“性能红利”

所有上层应用的性能飞跃,都源自底层的坚实支撑。面对“性能不够极致”的质疑,2025年8月发布的 Go 1.25 祭出了近年来针对云原生场景最“贴心”的三大杀招,直接回击了对 Go 运行时的效率诟病。

Cgroup 智能感知:终于读懂了容器的心

长期以来,Go 应用在容器中运行时有一个痛点:GOMAXPROCS 默认会“误以为”自己拥有宿主机的所有逻辑 CPU 资源。当容器被 Cgroup V2 严格限制了 CPU 配额(Quota)时,Go 运行时仍会创建过多的系统线程,导致严重的上下文切换(Context Switching)和性能抖动。

Go 1.25 终于引入了 Cgroup-Aware GOMAXPROCS。Go 运行时现在能周期性地自动检测容器的 Cgroup CPU 配额,并动态调整内部的并发级别。这直接减少了无谓的线程争用,让运行在 Kubernetes Pod 中的 Go 服务(尤其是那些资源受限的 Sidecar 或 Agent)无需人工调优即可获得更稳定、更高效的表现。

GreenTea GC:向“GC 暂停”宣战

为了应对高吞吐量场景下的延迟敏感需求,Go 1.25 带来了实验性的 GreenTea GC。这是一款专门针对“小对象密集型”应用(如日志收集器、OpenTelemetry Collector、K8s 控制器)进行优化的垃圾回收器。

GreenTea GC 改进了内存局部性,并大幅提高了标记阶段的并行性。在典型负载下,总体 GC 开销降低约 40%,显著改善了 P99 尾部延迟。这是 Go 在面对 Rust “零成本抽象”挑战时的一次强力技术回应,证明了带 GC 的语言在高性能领域依然能打。

JSON/v2:零内存分配的极速体验

标准库中的 encoding/json 曾是著名的性能瓶颈,其依赖运行时的反射机制导致了较高的 CPU 和内存消耗。Go 1.25 重写的 encoding/json/v2 彻底改变了这一局面。 这次重写带来了 3-10 倍 的反序列化速度提升,并实现了关键的“零堆内存分配”特性。对于 Kubernetes API Server 这种每天处理海量 JSON 配置和状态更新的组件来说,这意味着巨大的 CPU 周期节省和内存压力释放,直接提升了整个集群控制平面的吞吐上限。


基础设施:Kubernetes 与容器运行时的演进

Kubernetes v1.35:更聪明的 AI 调度

作为 Go 语言的“长子”,Kubernetes 在 2025 年 11 月迎来了 v1.35 版本。除了常规的稳定性提升,最引人注目的是其调度器针对 AI/ML 工作负载的进化。这意味着 K8s 能够更精细地处理 AI 训练任务对 GPU、内存等资源的苛刻要求,实现基于阈值的资源匹配。Go 语言高效的并发模型支撑了这一日益复杂的调度逻辑。

同时该新版本还引入了基于阈值的Extended Toleration Operators,新增了 Gt (大于) 和 Lt (小于) 等逻辑。

除了 v1.35 的调度增强,K8s 在 2025 年上半年的两个版本中也引入了多项值得关注的改进:

  • DRA (Dynamic Resource Allocation) 走向稳定:在 v1.34 中,DRA 的核心 API 将升级为 Stable。这为 GPU 等硬件加速器提供了更加灵活、标准化的资源请求和分配机制,摆脱了过去对非透明参数的依赖。
  • Sidecar 容器支持增强:虽然 Service Mesh 正在去 Sidecar 化,但 K8s 本身对 Sidecar 的原生支持却在加强。v1.33 引入了 In-place Pod Resize(原地调整 Pod 资源)的 Beta 支持,允许在不重启 Pod 的情况下动态调整容器的 CPU/内存限制,这对有状态应用和长连接服务至关重要。
  • 安全性加固:v1.33 默认启用了对 Linux Pod 的 User Namespaces 支持,显著降低了容器逃逸风险;同时,kubelet 开始支持使用 ServiceAccount Token 拉取镜像,逐步淘汰长期的 Image Pull Secrets。

容器运行时:containerd vs. CRI-O 的双雄格局

在彻底移除 dockershim 后,容器运行时生态形成了双雄并立的局面,且均由 Go 语言驱动:
* containerd:功能全面、极其稳定,支持镜像管理、零停机更新,是 AWS EKS、Google GKE 等云厂商的默认首选。
* CRI-O:极简主义,专为 K8s 设计,启动更快,资源占用更低,适合边缘计算等对资源敏感的场景。

警钟长鸣:containerd 内存泄露事件

2025 年 11 月披露的 containerd 漏洞 (CVE-2025-64329) 给 Go 开发者敲响了警钟。该漏洞存在于 CRI Attach 实现中,用户重复调用 kubectl attach 可能导致 Goroutine 泄露,进而耗尽宿主机内存。这也反向推动了 Go 运行时可观测性的重要性(详见下文)。即便是内存安全的语言,如果并发控制不当,依然会导致资源枯竭。

Operator 的安全模型升级

Kubernetes Operator 是 Go 生态的另一大杀手锏。2025 年,Operator SDK 和 Kubebuilder 终于移除了对外部 kube-rbac-proxy 的依赖,转而使用 controller-runtime 库内置的 WithAuthenticationAndAuthorization 功能。指标端点(Metrics Endpoint)的安全保护逻辑被直接集成在 Go 代码的控制循环中。其带来的价值是架构更简单,攻击面更小,部署 Operator 变得“默认安全”。


架构演进:Service Mesh 与 Serverless 的新篇章

Istio Ambient Mesh:全面去 Sidecar 化

服务网格正在经历一场革命。2025 年,Istio 全力推广 Ambient Mesh 模式,旨在移除侵入式的 Sidecar 代理,提供更轻量、更快速的体验。
* 控制平面:Go 语言编写的控制平面(Istiod)在其中扮演了指挥官的角色,负责管理这一新型架构。
* 多集群突破:Istio 1.27 (Alpha) 引入了 Ambient 模式下的多集群流量管理,允许企业以Active-Active 模式运行高可用服务,利用 Go 驱动的控制逻辑优化跨区域流量成本。

Knative 毕业:Serverless 的成熟里程碑

2025 年 10 月,Knative 正式从 CNCF 毕业,标志着 Go 语言构建的 Serverless 抽象层已经完全成熟。Knative Eventing 新增了 RequestReply 资源,加强了同步与异步工作负载之间的桥接能力,进一步巩固了 Go 在构建复杂事件驱动架构(EDA)中的统治地位。

Go 在 IaC 中的隐形统治

在基础设施即代码(IaC)领域,虽然 Terraform (HCL) 占据前台,但如 PulumiAWS CDK 等开发者优先平台,正大量利用 Go 语言的静态类型优势和丰富的库生态作为后端逻辑支撑,提升了 IaC 的测试能力和抽象水平。


可观测性:OpenTelemetry 的“默认稳定”战略

OTel Go SDK:从“可用”到“默认稳定”

OpenTelemetry (OTel) 是云原生可观测性的事实标准。2025 年 11 月,OTel 治理委员会宣布了战略调整:确保所有分发版“默认稳定” (stable by default)

同时,OTel Go SDK 的 TracesMetrics 组件均已达到 Stable 状态,Logs SDK 处于 Beta。这标志着 Go 生态的可观测性基石已完全成熟,企业可放心在生产环境大规模部署。

运行时指标:从“Opt-In”到“Opt-Out”

为了更好地诊断像 containerd 内存泄露这样的问题,OTel Go SIG 正在推进一项关键变更:将 Go Runtime Metrics(如 GC 暂停时间、堆内存使用、Goroutine 数量)从“选择性开启”改为“默认开启” (Opt-Out)。这意味着运维人员能“开箱即用”地看到 Go 应用的内部健康状况,配合 OTel 的语义惯例,能够更早地发现由 GC 或并发引起的潜在风险。

配置简化:YAML/JSON 文件支持

为了降低在 K8s 中的部署难度,OTel Go SDK 正在增强对 YAML/JSON 文件配置的支持,改变了过去过度依赖环境变量的局面,提升了配置的灵活性和易用性。

里程碑:OpenTelemetry eBPF Instrumentation (OBI) 正式发布

2025 年 11 月,OpenTelemetry 社区迎来了一个重磅时刻:OpenTelemetry eBPF Instrumentation (OBI) 发布了首个 Alpha 版本。

  • 零侵入,全覆盖:OBI 利用 eBPF 技术在内核层进行观测,无需修改代码、无需重启服务、无需引入任何应用依赖,即可实现对 HTTP, gRPC, SQL (MySQL, PostgreSQL), Redis, Kafka 等多种协议的自动追踪和指标采集。
  • 多语言一致性:无论你的应用是 Go, Java, Python 还是 Node.js 编写的,OBI 都能提供统一、标准的遥测数据。这对于那些包含遗留系统或多语言技术栈的企业来说,是实现全链路可观测性的“银弹”。
  • 与 SDK 的互补:OBI 并非要取代传统的 SDK 插桩。它更适合作为“基线”观测手段,快速覆盖所有服务;而对于需要深入应用内部逻辑(如业务埋点、复杂上下文传播)的场景,结合使用 OTel Go SDK 依然是最佳实践。

巅峰对决:Go vs. Rust 在 2025

我们在这里回答前面的问题:面对 Rust 的围剿,Go 守住了吗?

  • Go 的基本盘(铁王座):在控制平面(Control Plane)、API 网关、K8s Operator 以及企业级微服务等需要快速迭代、高并发协作的领域,Go 依然是绝对王者。其极低的心智负担、极高的开发效率和成熟的生态,是 Rust 短期内难以撼动的。
  • Rust 的突围(特种兵):在数据平面(Data Plane)(如 Envoy 插件)、高性能计算等对内存安全和尾部延迟有苛刻要求的领域,Rust 凭借“零 GC”和编译期内存安全检查,确实撕开了一道口子,比 Go 快约 1.5 倍,且没有 GC 抖动。

2025 年的格局:Go 没有坐以待毙。通过 GreenTea GC 降低 40% 的 GC 开销,通过 JSON/v2 消除反射带来的性能损耗,Go 正在努力拉高性能下限,防止被 Rust 侵蚀核心领地。对于大多数云原生应用来说,Go 依然是综合成本(开发效率+运行效率)最低、最稳妥的选择


总结与建议

2025 年,Go 语言没有停下脚步。通过 Go 1.25 的底层革新,它补齐了在容器化环境和 JSON 处理上的短板;通过 K8s 和 OTel 的持续演进,它在云原生生态中构建了更坚固的防线。

面对 Rust 的围剿,Go 不仅守住了铁王座,还通过自我进化,让这个王座变得更加稳固。

给技术团队的建议:

  1. 尽快升级:将核心服务升级到 Go 1.25+,白嫖 Cgroup 感知和 JSON 性能提升,这对于降本增效立竿见影。
  2. 拥抱 OTel:采用 OpenTelemetry Go SDK(虽然有些复杂^_^),并利用默认开启的运行时指标,建立更精细的监控体系,防范 Goroutine 泄露等隐形杀手。
  3. 理性选型:对于绝大多数业务服务和控制平面,坚持使用 Go;只有在极少数对延迟极其敏感、且逻辑相对稳定的数据平面组件中,才考虑引入 Rust。

Go 的 2025,是稳中求进、自我革新的一年。云原生的未来,依然写满了 Go 的名字。


参考资料

本文基于 2025 年多份权威技术报告与社区动态整理而成,涵盖 CNCF、Go 官方博客、Kubernetes 发布说明及 OpenTelemetry 社区公告等。

  1. Golang in 2025: Usage, Trends, and Popularity - Medium, accessed November 28, 2025, https://medium.com/@datajournal/golang-in-2025-usage-trends-and-popularity-3379928dd8e2
  2. The Go Ecosystem in 2025: Key Trends in Frameworks, Tools, and Developer Practices, accessed November 28, 2025, https://blog.jetbrains.com/go/2025/11/10/go-language-trends-ecosystem-2025/
  3. Go: Driving The Next Wave of Cloud-Native Infrastructure - Open Source For You, accessed November 28, 2025, https://www.opensourceforu.com/2025/11/go-driving-the-next-wave-of-cloud-native-infrastructure/
  4. Go 1.25 Highlights: How Generics and Performance Define the …, accessed November 28, 2025, https://dev.to/leapcell/go-125-highlights-how-generics-and-performance-define-the-future-of-go-4pdh
  5. Kubernetes v1.35 Sneak Peek, accessed November 28, 2025, https://kubernetes.io/blog/2025/11/26/kubernetes-v1-35-sneak-peek/
  6. Kubernetes v1.35 Release Highlights #2903 - GitHub, accessed November 28, 2025, https://github.com/kubernetes/sig-release/discussions/2903
  7. Top Docker Alternatives in 2025: A Complete Guide - DataCamp, accessed November 28, 2025, https://www.datacamp.com/blog/docker-alternatives
  8. 15 Best Docker Alternatives for 2025: Complete Guide with Pros, Cons & Migration, accessed November 28, 2025, https://signoz.io/comparisons/docker-alternatives/
  9. CVE-2025-64329: containerd CRI server: Host memory exhaustion through Attach goroutine leak - GitLab Advisory Database, accessed November 28, 2025, https://advisories.gitlab.com/pkg/golang/github.com/containerd/containerd/v2/CVE-2025-64329/
  10. CVE-2025-64329: containerd CRI Attach Memory DoS - Miggo Security, accessed November 28, 2025, https://www.miggo.io/vulnerability-database/cve/CVE-2025-64329
  11. operator-framework/operator-sdk: SDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding. - GitHub, accessed November 28, 2025, https://github.com/operator-framework/operator-sdk
  12. Repo for the controller-runtime subproject of kubebuilder (sig-apimachinery) - GitHub, accessed November 28, 2025, https://github.com/kubernetes-sigs/controller-runtime
  13. Metrics - The Kubebuilder Book, accessed November 28, 2025, https://book.kubebuilder.io/reference/metrics.html?highlight=metr
  14. Istio / Istio Roadmap for 2025-2026, accessed November 28, 2025, https://istio.io/latest/blog/2025/roadmap/
  15. Cloud Native Computing Foundation Announces Knative’s Graduation | CNCF, accessed November 28, 2025, https://www.cncf.io/announcements/2025/10/08/cloud-native-computing-foundation-announces-knatives-graduation/
  16. The 16 Best Infrastructure As Code (IaC) Tools In 2025 - Apiiro, accessed November 28, 2025, https://apiiro.com/blog/best-iac-tools/
  17. Evolving OpenTelemetry’s Stabilization and Release Practices, accessed November 28, 2025, https://opentelemetry.io/blog/2025/stability-proposal-announcement/
  18. Go - OpenTelemetry, accessed November 28, 2025, https://opentelemetry.io/docs/languages/go/
  19. OpenTelemetry Go 2025 Goals, accessed November 28, 2025, https://opentelemetry.io/blog/2025/go-goals/
  20. Configuration - OpenTelemetry, accessed November 28, 2025, https://opentelemetry.io/docs/collector/configuration/
  21. Prometheus with Grafana: 5 Compelling Use Cases - Tigera.io, accessed November 28, 2025, https://www.tigera.io/learn/guides/prometheus-monitoring/prometheus-grafana/
  22. Top Prometheus Exporters in 2025 and How to Use Them Effectively - GoCodeo, accessed November 28, 2025, https://www.gocodeo.com/post/top-prometheus-exporters-in-2025-and-how-to-use-them-effectively
  23. Rust vs Go in 2025: Comparison of Performance, Complexity, and …, accessed November 28, 2025, https://evrone.com/blog/rustvsgo
  24. Rust vs Go: Which one to choose in 2025 | The RustRover Blog, accessed November 28, 2025, https://blog.jetbrains.com/rust/2025/06/12/rust-vs-go/
  25. Your Complete Guide to KubeCon + CloudNativeCon North America 2025 | CNCF, accessed November 28, 2025, https://www.cncf.io/blog/2025/11/06/your-complete-guide-to-kubecon-cloudnativecon-north-america-2025/

还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


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

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

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

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

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


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

© 2025, bigwhite. 版权所有.