本文永久链接– https://tonybai.com/2025/06/27/from-java-to-go大家好，我是Tony Bai。各位Gopher以及正在望向Go世界的Java老兵们，近些年，我们能明显感觉到一股从Java等“传统豪强”语言转向Go的潮流。无论是追求极致的并发性能、云原生生态的天然亲和力，还是那份独有的简洁与高效，Go都吸引了无数开发者。然而，从Java的“舒适区”迈向Go的“新大陆”，绝不仅仅是学习一套新语法那么简单，它更像是一场思维模式的“格式化”与“重装”。作为一名在Go语言世界摸爬滚打多年的Gopher，我见过许多优秀的Java开发者在初探Go时，会不自觉地带着一些“根深蒂固”的Java习惯。这些习惯在Java中或许是最佳实践，但在Go的语境下，却可能显得“水土不服”，甚至成为理解和掌握Go精髓的绊脚石。今天，我就从Gopher的视角，和大家聊聊那些Java开发者在转向Go时，最需要刻意“掰过来”的几个习惯。希望能帮助大家更顺畅地融入Go的生态，体会到Go语言设计的精妙之处。习惯一：接口的“名分”执念 -> 拥抱“能力”驱动Java的习惯：在Java世界里，接口（Interface）是神圣的。一个类要实现一个接口，必须堂堂正正地使用 implements 关键字进行声明，验明正身，告诉编译器和所有开发者：“我，某某类，实现了某某接口！” ...继续阅读 (3)

本文永久链接– https://tonybai.com/2025/06/26/non-deterministic-abstraction大家好，我是Tony Bai。在软件开发领域，Martin Fowler 的名字几乎等同于思想的灯塔。他的每一篇文章、每一次演讲，都能为我们揭示行业发展的深层脉络。最近，Fowler 大师又发布了一篇简短但引人深思的博文——《LLMs bring new nature of abstraction》，再次精准地捕捉到了一个正在发生的、可能颠覆我们认知和工作方式的巨大变革。Fowler 认为，大型语言模型（LLM）的出现，对软件开发的影响，堪比从汇编语言到首批高级编程语言（HLLs）的飞跃。但关键在于，LLM 带来的不仅仅是又一个“更高层次”的抽象，它正在从根本上改变编程的“本质”——迫使我们思考，用“非确定性工具”进行编程究竟意味着什么。在这篇文章中，我们就来简单解读一下。从“确定性”的阶梯到“非确定性”的岔路回顾编程语言的发展史，我们一直在追求更高层次的抽象，以提升生产力、降低复杂度：汇编语言 vs. 机器指令：汇编让我们用助记符替代了 0 和 1，但仍需关注特定机器的寄存器和指令集。高级语言 (HLLs) vs. 汇编：Fortran、COBOL 等早期 HLLs 让我们能用语句、条件、循环来思考，而不用关心数据如何在寄存器间移动。 ...继续阅读 (3)

本文永久链接– https://tonybai.com/2025/06/24/grab-rewrote-go-service-in-rust大家好，我是Tony Bai。最近，东南亚科技巨头、出行公司 Grab 的一篇技术博客《Counter Service: How we rewrote it in Rust》在技术圈引起了不小的震动。他们将一个高 QPS（每秒查询率）的 Go 微服务（Counter Service）用 Rust 进行了重写，结果令人瞩目：在保持相似 P99 延迟性能的前提下，基础设施成本降低了高达 70%！。P99延迟对比：Go（紫色），Rust（蓝色）这个案例无疑给许多以 Go 作为主力语言的团队和开发者带来了强烈的冲击。Go 语言以其简洁、高效并发、快速编译以及强大的生态系统，在微服务、云原生领域早已占据重要地位。那么，Grab 的这次成功“叛逃”，是否意味着 Go 语言在某些场景下的“护城河”正在被侵蚀？Rust 真的是解决一切性能和成本问题的“银弹”吗？今天，我们就来深入剖析 Grab 的这个重构案例，看看他们究竟“得”了什么，“失”了什么，以及这背后能给咱们 Gopher 带来哪些宝贵的启示。Rust 的“杀手锏”：极致效率带来的基础设施成本骤降Grab 的 Counter Service 主要负责计数和提供 ML 模型/欺诈规则的计数器 ...继续阅读 (7)

本文永久链接– https://tonybai.com/2025/06/22/unexpected-security-footguns-in-go-parsers大家好，我是Tony Bai。在 Go 语言中，标准库的 encoding/json 包无疑是我们日常打交道最多的伙伴之一。它简洁易用，性能尚可，支撑了无数 Go 应用的数据交换需求。然而，正如俗话所说，“最熟悉的地方可能藏着最深的坑”，最近拜读了知名安全公司 Trail of Bits 的一篇深度剖析文章——“Unexpected security footguns in Go’s parsers”（Go 解析器中意想不到的安全“绊脚石”）——让我对这个朝夕相处的伙伴有了全新的、甚至可以说是“惊出一身冷汗”的认识。这篇文章系统性地揭示了 Go 标准库中的 JSON、XML（以及流行的第三方 YAML）解析器在处理非受信数据时，存在一些设计上或默认行为上的“特性”，这些“特性”在特定场景下很容易被攻击者利用，演变成严重的安全漏洞。文中提到的真实案例，如 Hashicorp Vault 的认证绕过 (CVE-2020-16250)，更是触目惊心。今天，我们就结合 Trail of Bits 的这篇“檄文”，深入挖掘一下 Go 解析器（特别是我们最常用的 encoding/json）的那些“隐秘角落”， ...继续阅读 (9)

本文永久链接– https://tonybai.com/2025/06/21/kubernetes-2-0大家好，我是Tony Bai。自 2014 年首次提交以来，Kubernetes 已走过辉煌的十年。它从一个“没人能念对名字”的希腊词汇，成长为容器编排领域无可争议的事实标准，深刻地改变了我们构建、部署和管理应用的方式。我们不再满足于在服务器层面“管理基础设施”，一切都变得声明式、可扩展、可恢复，甚至（如果你足够幸运的话）能够自我修复。然而，正如任何伟大的技术旅程一样，Kubernetes 的发展也并非一帆风顺。尽管它带来了巨大的生产力提升，但其陡峭的学习曲线、某些领域“不够固执己见 (not opinionated enough)”导致的常见错误和配置失误、以及生态系统中持续的“变动”，仍然让许多开发者和运维者“痛并快乐着”。我们依然会踩到那些文档早已记录的“地雷”。站在十年的重要节点，回望过去，展望未来，一个有趣的问题自然而然地浮现：如果我们有机会基于今天的认知和经验，重新构想一个 Kubernetes 2.0，它会是什么样子？我们能做哪些改变，让这个伟大的工具更普惠、更强大、更易用？最近，一篇题为《What Would a Kubernetes 2.0 Look Like》的博文，就针对这个问题提出了一系列大胆而深刻的畅想，直指当前 K8s 生态中的核心痛点。 ...继续阅读 (8)

本文永久链接– https://tonybai.com/2025/06/20/about-errors-join大家好，我是Tony Bai。错误处理，无疑是软件开发中永恒的核心议题之一。Go 语言以其独特的、显式的错误处理机制（即 error 作为普通值返回）而著称，这种设计强调了对错误的关注和及时处理。自Go 1.13 引入错误包装 (wrapping) 机制以来，Go 的错误处理能力得到了显著增强。而在Go 1.20 版本中，标准库 errors 包更是带来了一个备受关注的新成员：errors.Join() 函数。这个函数允许我们将多个 error 值合并成一个单一的 error 值，并且合并后的错误依然可以通过 errors.Is 和 errors.As 进行检查。一时间，社区中对其评价不一：有人称之为“天赐之物”，认为它在特定场景下能极大提升代码表达力和用户体验；也有人持审慎态度，强调应坚守“快速失败 (Fail Fast)”的原则，避免滥用错误聚合。那么，errors.Join() 究竟是解决特定痛点的“良药”，还是可能被误用的“潘多拉魔盒”？它与 Go 一贯倡导的错误处理哲学是相辅相成，还是有所背离？今天，我们就结合社区的讨论，深入探讨 errors.Join() 的适用场景、潜在风险以及最佳实践。errors.Join()：是社区呼声的产物，还是多此一举 ...继续阅读 (6)

本文永久链接– https://tonybai.com/2025/06/18/inside-goroutine-scheduler-column你好，我是Tony Bai。欢迎踏上一次深入Go并发核心的探索之旅——【Go并发调度艺术】微专栏。我们每天都在使用go关键字轻松驾驭并发，享受着Go语言带来的编程乐趣。但在这简洁的背后，是一套复杂而精密的调度系统在默默支撑。它如同一位技艺精湛的指挥家，巧妙地调度着成千上万的goroutine，在用户态的轻盈与操作系统的力量之间取得了绝妙的平衡。许多Go开发者为了面试，会去“背诵”GMP模型的概念，记忆那些零散的知识点。但这种学习方式往往浮于表面，难以形成深刻的理解，更不用说将其内化为指导我们编写高效并发程序的工程直觉。这一次，我们换个视角，不再是被动接受结论，而是主动参与“设计”。本微专栏的核心特色，是跟随Go调度器的核心设计者之一Dmitry Vyukov的思考路径（基于其经典的Go调度器设计资料）。我们将设身处地，从他最初面临的设计目标和挑战开始，一步步看他是如何分析问题、尝试方案、做出权衡，并最终构建出我们今天所熟知的、强大的Go调度器的。在这个微专栏中，你将“亲历”：并发的初心与抉择：Go为什么需要自己的调度器？面对轻量化、大规模并发的严苛目标，为何OS线程模型捉襟见肘？早期M:N模型的探索与瓶颈。可伸缩的引擎构建：全局 ...继续阅读 (10)

本文永久链接– https://tonybai.com/2025/06/17/rider-elephant-arch大家好，我是Tony Bai。在软件架构的江湖里，关于“微服务”与“单体”的论战，几乎从未停歇。一方推崇微服务的灵活性、可扩展性和独立部署，另一方则坚守单体的简洁性、低通信开销和易于本地调试。近年来，我们甚至看到像亚马逊 Prime Video 这样重量级的玩家，也公开分享了其从微服务“回归”到某种形式的单体（或者说更粗粒度的服务）的实践，引发了业界新一轮的思考。这不禁让我们反问：微服务与单体，真的就是非此即彼的“二元对立”吗？最近，国外一家名为DealGate公司的一篇文章《Introducing the Rider and Elephant Software Architecture》，提出了一种他们称之为“骑手与大象”的架构模式，试图在这场看似无解的争论中，找到一条务实的中间道路。这种模式不仅在他们的实践中取得了显著成效，其背后的设计哲学和对技术选型的思考，也颇具启发意义。“骑手与大象”：一个古老隐喻的现代架构演绎DealGate 将其架构模式命名为“骑手与大象”，其灵感来源于心理学中的一个经典比喻：人类的思维由两部分组成——理性的“骑手”（对应我们发达的前额叶皮层，负责规划、分析和决策）和感性的、更强大的“大象”（对应我们原始的、更底层的“蜥蜴脑” ...继续阅读 (15)

本文永久链接– https://tonybai.com/2025/06/16/go-avoid-critical-incident大家好，我是Tony Bai。科技圈的每一次“风吹草动”，尤其是大型云服务的故障，总能引发我们技术人无数的讨论与反思。最近，一则关于“Google Cloud Platform (GCP) Service Control 在 2025 年 6 月发生重大故障”的消息，及其事后分析报告中直指的“null pointer crash loop”，在技术社区掀起了不小的波澜。故障报告中还提到了几个雪上加霜的因素：没有特性标志 (Feature Flags) 进行高风险部署、缺乏优雅的错误处理（二进制文件直接崩溃而非优雅降级）、以及没有回退机制导致系统过载。考虑到 Go 语言在 Google 内部（如 Kubernetes, Cloud Run 等）以及整个云原生领域的广泛应用，一个自然而然的疑问浮出水面：Go语言是否是这次 GCP 故障的“元凶”？或者说，Go 的某些特性，是否在某种程度上“助长”了这类问题的发生？反过来，Go 的设计又是否本可以帮助避免这样的灾难？这这篇文章中，我们就结合社区的智慧，从Go语言特性和更广泛的软件工程实践角度，来剖析一下这类故障背后的深层原因。这不仅是对一个故障的假想复盘，更是对我们日常开发实践的一次警醒。Go 语言 ...继续阅读 (11)

本文永久链接– https://tonybai.com/2025/06/15/rust-vs-go-2025大家好，我是Tony Bai。技术圈的话题里，从来不缺少编程语言之争，并且这类话题向来热度不减。最近，JetBrains 旗下的 RustRover 博客发表了一篇题为《Rust vs Go: Which one to choose in 2025》的文章，并引用了《State of Developer Ecosystem Report 2024》的一些数据，再次将 Go 和 Rust 这两位“当红炸子鸡”推上了对比的擂台。文章指出，Rust 和 Go 都在现代计算领域开辟了重要的生态位，尤其在系统级操作和并发处理方面备受赞誉。报告数据也颇为亮眼：Rust 的用户基数已达到约 227 万，其中 70.9 万开发者将其作为主要语言；而 Go 的用户基础依然稳固。但一个颇具“引战”潜力的数据点是——“约 1/6 的 Go 用户正在考虑转向 Rust”。这不禁让人深思：这是否预示着某种趋势？在即将到来的 2025 年，当面临新的项目或技术升级时，我们究竟应该选择 Go 还是 Rust？作为一名在 Go 领域深耕多年的老兵，我想结合 RustRover 的这篇文章，谈谈我的一些看法，希望能为正在做技术选型的你，提供一些来自 Go 视角的参考。文章核心观点速览(与Go的对比 ...继续阅读 (15)

本文永久链接– https://tonybai.com/2025/06/14/go-1-25-foresight大家好，我是Tony Bai。每年，Go 语言都会以其严谨而高效的节奏，带来两次版本更新。每一次迭代，Go 团队都在底层、工具链和标准库上持续深耕，为我们开发者提供更稳健、更高效、更安全的开发体验。虽然 Go 1.25 的正式版预计在 2025 年 8 月发布，但随着近期Go 1.25RC1版本的推出，我们基于其非最终版的 Release Notes，已经能一窥其核心亮点了。并且，和之前的版本一样，Go 1.25 带来的许多改进，都如同“无形之手”，你可能无需修改一行代码，甚至无需刻意感知，只需简单升级，便能享受到性能的飞跃、诊断能力的提升以及潜藏错误的暴露。这正是 Go 团队践行其核心原则的极致体现。今天，就让我们一起“未雨绸缪”，聚焦 Go 1.25 中的核心特性，看看它将如何让 Go 语言变得更加强大。语言层面：兼容至上，细微进化Go语言对向后兼容性的承诺，是其最受开发者赞誉的特性之一。Go 1.25 再次延续了这一传统：它没有引入任何影响现有 Go 程序的语言语法变更！这意味着你可以放心地升级到 Go 1.25，而无需担忧已有的代码库会因此“崩溃”。尽管如此，语言规范层面仍有细微的整理和优化，例如移除了“core type”的概念，代之以更详细的描述。 ...继续阅读 (14)

本文永久链接– https://tonybai.com/2025/06/12/grog-brain-heaven大家好，我是Tony Bai。最近，在国外的技术论坛 Reddit 的 Go 语言版块上，一个标题为“Go is so much fun, Grog brain heaven”的帖子，引爆了 Gopher 们的讨论热情。发帖的开发者用一种非常接地气的“原始人 (Grog)”口吻，激情赞扬了 Go 语言，核心就一个字——“爽！”他列举了一堆理由：关键词少、特殊字符少、概念少、编译器快、工具链好用、标准库给力、没有复杂的构建系统……总而言之，Go 语言对于那些厌倦了复杂性、只想专注于“造东西”的开发者来说，简直就是“天堂”。这个帖子迅速获得了大量 Go 开发者的强烈共鸣。一位从 Scala 转到 Go 的开发者形容这种体验像是“从100倍重力训练环境出来，到了只有1倍重力的地方，认知负荷大大降低。在Go里你就是直接做事，没有魔法，没有废话，简单直接。” 另一位开发者则惊叹于 Go 工具链的便捷：“只需安装 SDK 就完事了！” 更有甚者直言，Go 的杀手级特性恰恰在于其“缺乏特性 (lack of features)”。这些发自肺腑的“声音”，不禁让我们深思：在这个技术日新月异、语言特性层出不穷的时代，为什么 Go 语言这种看似“朴素”的“简单”，反而能让如此多的 ...继续阅读 (24)

本文永久链接– https://tonybai.com/2025/06/11/the-gentle-singularity大家好，我是Tony Bai。近日，OpenAI 的掌舵人 Sam Altman 在其个人博客上发表了一篇题为《The Gentle Singularity》（温和的奇点）的重磅文章，再次将人工智能的未来推向了舆论的风口浪尖。Altman 以其一贯的前瞻性视角，大胆宣称：“我们已越过事件视界；起飞已经开始。人类已接近构建数字超级智能，而且至少到目前为止，它远没有看起来那么怪异。”这番“奇点宣言”无疑是震撼性的。它不仅暗示着 AI 发展的某个关键转折点已经到来，更描绘了一个由 AI 驱动的、既熟悉又陌生的未来。那么，Altman 的“温和奇点”究竟意味着什么？我们是否真的站在了一个新时代的门槛上？本文就来转述和提炼一下Altman的观点，分享给大家，期望能引发各位小伙伴儿的思考。“不那么怪异”的超智能迹象：奇迹正在常态化Altman 开篇即指出，尽管机器人尚未遍布街头，我们大多数人也并非整日与 AI 对话，人类依然面临疾病、太空探索的困境以及对宇宙的诸多未知，但一个不争的事实是：“我们最近构建的系统在很多方面比人类更聪明，并且能够显著放大使用者的产出。”他认为，通往通用人工智能（AGI）道路上“最不可能的部分已经过去”。那些让我们得以拥有像 GPT-4 ...继续阅读 (19)

本文永久链接– https://tonybai.com/2025/06/09/go-simd-intrinsics大家好，我是Tony Bai。长期以来，在Go语言中追求极致性能的开发者，当遇到需要利用现代 CPU 的 SIMD (Single Instruction, Multiple Data) 能力时，往往不得不求助于手写汇编。这种方式不仅编写和维护困难，还会导致异步抢占失效、阻碍编译器内联优化等问题。现在，这一“不得不”的时代有望终结。Go 官方团队正式提出了#73787 提案：在 GOEXPERIMENT 标志下引入架构特定的 SIMD 内置函数。这一里程碑式的提案，旨在为 Go 开发者提供一种无需编写汇编即可利用底层硬件加速能力的方式，预示着 Go 在高性能计算领域将迎来一场深刻的巨变。在这篇文章中，我就和大家一起解读一下这个里程碑式的提案。两步走战略：从架构特定到可移植 HighwayGo 语言的 API 设计一向以简洁和可移植性著称，但 SIMD 操作的本质却是硬件特定且复杂的。不同 CPU 架构（如 amd64, arm64, riscv64 等）支持不同的向量长度、操作指令甚至数据表示方式。如何在高层抽象的简洁性与底层硬件的复杂性之间找到平衡，是 Go SIMD 设计面临的核心挑战。为此，Go 团队提出了一个清晰的“两步走”战略：第一步：低级、架构特 ...继续阅读 (24)

本文永久链接– https://tonybai.com/2025/06/07/allow-serving-module-under-subdir大家好，我是Tony Bai。对于许多 Go 项目维护者而言，如何优雅地组织一个包含多种语言或多个独立 Go 模块的 Git 仓库一直是个不大不小的难题。将 Go 模块置于仓库根目录虽然直接，但有时会导致根目录文件列表臃肿，影响项目整体的清爽度。而将 Go 模块移至子目录，则面临着导入路径、版本标签以及 Go 工具链支持等一系列挑战。近日，一个旨在解决这一痛点的提案 (Issue #34055) 在历经数年讨论后，终于被 Go 团队正式接受，并将在 Go 1.25 版本中落地。这一变化预示着 Go 模块的管理将迎来更高的灵活性。在这篇文章中，我就来介绍一下这个Go模块管理的变化，各位读者也可以评估一下该功能是否会给你带来更多的便利。痛点：子目录模块的困境提案发起者 @nhooyr 在其 websocket 项目 (nhooyr.io/websocket) 中遇到了典型的问题：当 Go 模块文件直接放在 Git 仓库根目录时，根目录显得非常杂乱。他尝试将 Go 模块移至子目录（例如 ./mod），希望 nhooyr.io/websocket 这个导入路径能直接指向该子目录，而不是变成 nhooyr.io/websocket/mod ...继续阅读 (19)

本文永久链接– https://tonybai.com/2025/06/06/go-monorepo大家好，我是Tony Bai。在Go语言的生态系统中，我们绝大多数时候接触到的项目都是遵循“一个代码仓库（Repo），一个Go模块（Module）”的模式。这种清晰、独立的组织方式，在很多场景下都运作良好。然而，当我们放眼业界，特别是观察像Google这样的技术巨头，或者深入研究etcd这类成功的开源项目时，会发现另一种代码组织策略——Monorepo（单一代码仓库）——也在扮演着越来越重要的角色。与此同时，Go语言的依赖管理从早期的GOPATH模式（其设计深受Google内部Monorepo实践的影响）演进到如今的Go Modules，我们不禁要问：在现代Go工程实践中，尤其是面对日益复杂的项目协作和特殊的交付需求（如国内甲方普遍要求的“白盒交付”），传统的Single Repo模式是否依然是唯一的最佳选择？Go项目是否也应该，或者在何种情况下，考虑拥抱Monorepo？这篇文章，就让我们一起深入探讨Go与Monorepo的“前世今生”，解读不同形态的Go Monorepo实践（包括etcd模式），借鉴Google的经验，剖析其在现代软件工程，特别是白盒交付场景下的价值，并探讨相关的最佳实践与挑战。Go Monorepo的形态解读：不仅仅是“大仓库”首先，我们需要明确什 ...继续阅读 (28)

本文永久链接– https://tonybai.com/2025/06/04/error-syntax大家好，我是Tony Bai。长久以来，Go 语言中 if err != nil 的错误处理模式因其普遍性和由此带来的代码冗余，一直是社区反馈中最持久、最突出的痛点之一。尽管 Go 团队及社区投入了大量精力，历经近十五年的探索，提出了包括 check/handle、try 内建函数以及借鉴 Rust 的 ? 操作符在内的多种方案，但始终未能就新的错误处理语法达成广泛共识。近日，Go 官方团队通过一篇博文正式阐述了其最新立场：在可预见的未来，将停止寻求通过改变语法来简化错误处理，并将关闭所有相关的提案。这一决策无疑在 Go 社区引发了广泛关注和深入思考。漫漫探索路：从 check/handle 到 ? 操作符Go 语言的错误处理冗余问题，尤其在涉及大量 API 调用且错误处理逻辑相对简单的场景下尤为突出。一个典型的例子如下：func printSum(a, b string) error { x, err := strconv.Atoi(a) if err != nil { return err // 样板代码 } y, err := strconv.Atoi(b) if err != nil { r ...继续阅读 (23)

本文永久链接– https://tonybai.com/2025/06/03/provocation-about-ai-assisted-programming大家好，我是Tony Bai。最近，fly.io 博客上该公司开发者 Thomas Ptacek 的一篇题为《My AI Skeptic Friends Are All Nuts》的文章，在开发者社区掀起了不小的波澜，一度登顶HN。Ptacek 以一位自称“严肃开发者”（从C语言到Go、Rust均有涉猎）的口吻，向那些对 AI 辅助编程持怀疑态度的“聪明朋友们”发出了略带“挑衅”的宣言：“即使 LLM 今天停止所有进展，它仍然是我职业生涯中发生的第二重要的事情”。这篇文章的观点之鲜明、论证之犀利，让我印象深刻。恰逢 前期Google I/O 2025 大会再次展示了 Gemini 等 AI 模型在编码领域的惊人进展，我们不禁要问：AI 编码工具，究竟是能极大提升生产力的“真香”利器，还是又一轮被过度炒作的“智商税”？作为开发者，特别是 Gopher，我们又该如何看待和应对这场正在发生的变革？在这篇文章中，我就和大家一起来看看 Thomas Ptacek 对AI辅助编程演进的犀利观点以及他的反思。看看你是否认同他的想法。误区澄清：现代 AI 辅助编程早已不是“复制粘贴”Ptacek 在文章开篇就点出了一个关键问题： ...继续阅读 (22)

本文永久链接– https://tonybai.com/2025/06/03/lightweight-anonymous-func-syntax大家好，我是Tony Bai。自2017年提出以来，Go语言关于引入轻量级匿名函数语法的提案（Issue #21498）一直是社区讨论的焦点。该提案旨在提供一种更简洁的方式来定义匿名函数，尤其是当函数类型可以从上下文推断时，从而减少样板代码，提升代码的可读性和编写效率。然而，历经七年多的广泛讨论、多种语法方案的提出与激辩，以及来自核心团队成员的实验与分析，截至 2025年5 月底，官方对该提案的最新立场是“可能被拒绝 (likely declined)”，尽管问题仍保持开放以供未来考虑。近期该issue又冲上Go issue热度榜，让我有了对该提案做一个简单解读的冲动。在本文中，我将和大家一起探讨该提案的核心动机、社区的主要观点与分歧、面临的挑战，以及这一最新倾向对 Go 语言和开发者的潜在影响。冗余之痛：当前匿名函数的困境在Go中，匿名函数的标准写法是func(参数列表) (返回类型列表) { 函数体 }虽然这种语法明确且一致，但在许多场景下，尤其是作为回调函数或在函数式编程风格（如配合泛型和迭代器使用）中，参数和返回类型往往可以从上下文清晰推断，此时显式声明则显得冗余。提案发起者 Neil (neild) 给出了一个 ...继续阅读 (23)

本文永久链接– https://tonybai.com/2025/05/30/gopher-girlfriend大家好，我是Tony Bai。最近，一张名为 “gopher gf” (Go 语言女友) 的 Meme 图在开发者社区悄然流传，引得无数 Gopher 会心一笑。这张图用拟人化的“女友”特质，巧妙地描绘了 Go 语言的诸多优点和社区文化梗。那么，这位集万千宠爱于一身的“Go 语言女友”，究竟有哪些令人着迷的“可爱”特性呢？今天，就让我们化身“恋爱观察员”，逐条“解密”这张 Meme 图，看看 Go 语言是如何成为许多开发者心中“理想型”的。“Gopher 女友”的可爱特质大揭秘！让我们一起来看看这位“Gopher 女友”的闪光点，以及它们在 Go 语言世界中的真实写照：1. “cute” (可爱)Meme 解读：她有着 Gopher 吉祥物那标志性的、憨态可掬的可爱模样。Go语言真相：这首先让人联想到 Go 语言那只呆萌的土拨鼠吉祥物。更深层次来说，Go 语言的语法简洁、核心概念少、没有过多的“语法糖”，使得代码看起来清爽直接，就像一个不施粉黛、自然可爱的女孩，让人一见倾心。2. “low-maintenance” (低维护)Meme 解读：她不“作”，好相处，不需要你花太多心思去“伺候”。Go语言真相：这简直是 Go 语言的真实写照！gofmt 强制统一代码 ...继续阅读 (27)

本文永久链接– https://tonybai.com/2025/05/29/xiter-declined大家好，我是Tony Bai。随着 Go 1.22 中 range over func 实验性特性的引入，以及在 Go 1.23 中该特性的最终落地（#61405），Go 社区对迭代器（Iterators）的讨论达到了新的高度。在这一背景下，一项旨在提供标准迭代器适配器（Adapters）的提案 x/exp/xiter (Issue #61898) 应运而生，曾被寄予厚望，期望能为 Go 开发者带来一套便捷、统一的迭代器操作工具集。然而，经过社区的广泛讨论和官方团队的审慎评估，该提案最终被标记为“婉拒并撤回 (declined as retracted)”。本文将对 x/exp/xiter 提案的核心内容做个简单解读，说说社区围绕它的主要争论点，以及最终导致其搁浅的关键因素，并简单谈谈这一决策对 Go 语言生态的潜在影响与启示。x/exp/xiter：构想与核心功能x/exp/xiter 提案由 Russ Cox (rsc) 发起，旨在 golang.org/x/exp/xiter 包中定义一系列迭代器适配器。这些适配器主要服务于 Go 1.23 中引入的 range over func 特性，提供诸如数据转换 (Map)、过滤 (Filter)、聚合 (Reduc ...继续阅读 (33)

本文永久链接– https://tonybai.com/2025/05/26/monitor-design-with-red大家好，我是Tony Bai。随着业务的快速发展，越来越多的应用开始拥抱云原生。我们享受着微服务带来的解耦、容器带来的标准化、Kubernetes带来的弹性伸缩。但与此同时，一个灵魂拷问也摆在了每一位开发者和运维工程师面前：我的服务还好吗？用户用得爽吗？出问题了能快速定位吗？传统的只盯着CPU、内存、磁盘的监控方式，在高度动态和分布式的云原生环境下，常常显得力不从心，就像“瞎子摸象”，难以窥得全貌。我们需要一种更直接、更面向用户体验、更标准化的方法来衡量服务的健康状况。今天，我就结合一个通用的示例和大家说一套被业界广泛认可的服务监控黄金法则——RED方法，谈谈如何按照RED方法设计出简单又好用的监控指标与告警。什么是RED方法？RED方法并非什么高深莫测的理论，它非常简洁，由三个核心指标的首字母组成：R – Rate (请求速率)E – Errors (错误率)D – Duration (响应时长)这“三板斧”虽然简单，却直击服务质量的核心。它是由Grafana Labs的VP Product，同时也是Prometheus和OpenMetrics早期贡献者Tom Wilkie于2018年提出的，旨在为现代服务（尤 ...继续阅读 (32)

本文永久链接– https://tonybai.com/2025/05/25/go-at-googleio-2025大家好，我是Tony Bai。在Google I/O 2025大会上，Go 产品负责人 Cameron Balahan 和开发者关系负责人 Marc Dougherty 详细阐述了 Go 语言在生产力、生产就绪度和开发者体验方面的最新进展及未来规划。演讲强调了 Go 语言以规模化为核心的设计理念及其三大指导原则：生产力、超越语言的完整体验和生产就绪。重点介绍了Go 1.23和Go 1.24版本在生产力方面的革新，包括引入迭代器简化循环、gopls 的智能现代化能力以及通过 go get 管理 Go 工具链；在生产就绪性方面，突出了WebAssembly 支持的增强、安全体系的持续深化（特别是后量子密码学的透明集成和 FIPS-140 支持的便捷启用）以及核心性能的显著提升（如全新的 map 实现）。此外，演讲还强调了 Go 语言在 AI 基础设施构建中的核心地位，并展望了 Go 1.25+ 在 SIMD 支持、多核硬件优化等方向的探索，同时重申了 Go 1.0 的兼容性承诺。这里是基于演讲视频，借助AI整理的文字稿，我做了简单校对和格式调整，供大家参考。原视频链接：https://www.youtube.com/watch?v=kj80m-umOxs 建议 ...继续阅读 (31)

本文永久链接– https://tonybai.com/2025/05/23/go-api-design-mcp-sdk大家好，我是 Tony Bai。作为开发者，我们每天都在与 API 打交道——调用它们，设计它们，有时也会为糟糕的 API 设计而头痛不已。一个优秀的 API，如同一位技艺精湛的向导，能清晰、高效地引领我们通往复杂功能的彼岸；而一个蹩脚的 API，则可能像一座布满陷阱的迷宫，让我们步履维艰。那么，在 Go 语言的世界里，一个“好”的 API 应该是什么样子的？它应该如何体现 Go 语言简洁、高效、并发安全的哲学？它又如何在满足功能需求的同时，保持对开发者的友好和对未来的兼容？最近，Go 官方团队为 Model Context Protocol (MCP) 发起了一项 Go SDK 的设计讨论，并公开了其详细的设计草案以及一个初期的原型代码实现。这份设计稿与代码，在我看来，不仅仅是对 MCP 协议的 Go 语言实现规划，更是一份Go 官方团队关于 API 设计思考与实践的“公开课”。它向我们生动地展示了，在打造一个既强大又符合 Go 惯例 (Idiomatic Go) 的 SDK 时，需要在哪些维度进行权衡取舍，以及如何将 Go 的设计哲学融入到每一个细节之中。今天，就让我们一同走进这份设计稿和它的原型代码，探寻 Go 团队在 API 设计中所追求的“G ...继续阅读 (32)

本文永久链接– https://tonybai.com/2025/05/22/go-sbom-practice大家好，我是Tony Bai。近年来，软件供应链安全事件频发，从 SolarWinds 到 Log4Shell，每一次都给业界敲响了警钟。在这样的背景下，软件物料清单 (SBOM, Software Bill of Materials) 的重要性日益凸显。无论是甲方爸爸的硬性要求（尤其是在2B软件交付和白盒交付场景），还是我们自身对软件透明度和安全性的追求，SBOM 都已成为现代软件开发不可或缺的一环。那么，SBOM 究竟是什么？它为何如此重要？市面上有哪些主流的 SBOM 标准？我们又该如何为自己的 Go 项目（当然，也适用于 Java、JS 等其他语言项目）生成和使用 SBOM 呢？今天，我们就来一起深入探讨这些问题，为你揭开 SBOM 的神秘面纱。SBOM：你的软件“配料表”，为何如此重要？想象一下，我们购买食品时会关注配料表，了解其成分、产地和营养信息。SBOM 之于软件，就如同食品的配料表。它是一份正式的、结构化的清单，详细列出了构成某个软件产品的所有组件及其依赖关系。SBOM 的核心价值在于提升软件供应链的透明度和可管理性，从而增强安全性：透明度与可追溯性：清晰展示软件由哪些“零件”（开源库、第三方组件、内部模块等）组装而成，包括直接依赖和传递依赖， ...继续阅读 (43)

本文永久链接– https://tonybai.com/2025/05/21/go-crypto-audit大家好，我是 Tony Bai。信息安全是我们数字时代的基石。对于 Go 语言而言，其标准库中强大的 crypto 系列包一直是开发者构建安全应用的重要依赖。近日，Go 官方博客发布了一篇重要文章，详细介绍了一次由独立安全公司 Trail of Bits 对 Go核心密码学包进行的安全审计结果。这次审计不仅再次印证了 Go 在密码学领域的严谨投入，也揭示了 Go 在后量子密码学 (PQC) 和未来密码学 API 发展上的清晰规划。好消息是：审计结果非常积极！仅发现一个低风险问题（已在 Go 1.25 开发分支修复，且涉及的是非默认启用、Google 内部使用的 Go+BoringCrypto 集成）和少量建议性信息。这充分肯定了 Go 团队在密码学库开发中对安全性的高度重视和卓越实践。在这篇文章中，我们就来介绍这一对Go密码学领域具有里程碑意义的事件。安全审计的范围与 Go 的密码学设计原则Trail of Bits 的审计范围广泛，涵盖了 Go 标准库中核心的加密组件，这些组件同时也是新的原生FIPS 140-3模块的验证部分。具体包括：密钥交换：ECDH 和后量子密码的 ML-KEM (如 crypto/mlkem 包)。数字签名：ECDSA, RSA, 和 ...继续阅读 (28)

本文永久链接– https://tonybai.com/2025/05/19/shardedvalue-per-cpu-proposal大家好，我是Tony Bai。在追求极致性能的道路上，Go 语言凭借其简洁的并发模型和高效的调度器，赢得了众多开发者的青睐。然而，随着现代服务器 CPU核心数量的不断攀升，一些我们曾经习以为常的“快速”操作，在高并发、多核环境下，也逐渐显露出其性能瓶颈。其中，原子操作 (atomic operations)的扩展性问题，以及标准库中一些依赖原子操作的并发原语（如 sync.RWMutex）的性能表现，成为了社区热议的焦点。最近，fasthttp 的作者及 VictoriaMetrics 数据库的联合创始人 Aliaksandr Valiakin (valyala) 在 X.com 上的一番“叹息”，更是将原子计数器的扩展性问题推向了前台：Valyala 指出：“基于原子操作的计数器更新性能在多 CPU 核心上无法扩展，因为每个 CPU 核心在增量操作期间都需要从慢速内存中原子加载实际的计数器值。因此，实际性能受限于内存延迟（约 15ns，即每秒 6 千万次增量）。通过使用可缓存于 CPU L1 缓存的 per-CPU 计数器，可以将单 CPU 核心性能提升至每秒数十亿次增量。遗憾的是，Go 语言本身并未提供高效处理 per-CPU 数据 ...继续阅读 (38)

本文永久链接– https://tonybai.com/2025/05/16/energy-savings-if-abandon-https大家好，我是Tony Bai。如今，当我们浏览网页时，地址栏那把绿色的小锁和 HTTPS 前缀已是司空见惯。从网上银行到个人博客，再到每一个SaaS服务，HTTPS/TLS 加密几乎覆盖了互联网的每一个角落。它像一位忠诚的数字保镖，守护着我们在虚拟世界中的数据安全与隐私。然而，这位保镖并非“免费服务”。HTTPS/TLS 在带来安全的同时，也无可避免地引入了额外的计算和传输开销，直观感受便是连接速度可能略有减慢，传输数据量也略有增加。而且，随着我们对安全的追求永无止境，为了抵御更强大的计算破解能力，加密算法的密钥长度也在不断增加（例如从 RSA 1024位到2048位甚至更高，ECC 曲线的复杂度也在提升），这无疑进一步加剧了这些开销。那么，今天我们不妨来做一个大胆的，甚至有些“异想天开”的思想实验：如果在一夜之间，全球所有的网站都决定弃用 HTTPS/TLS，回归到“裸奔”的 HTTP 时代，理论上能为我们的地球节省多少电力呢？重要声明：这纯粹是一个思想实验，旨在通过一个极端的假设，引发我们对技术成本（特别是能源成本）和安全效益之间平衡的思考。我们绝非鼓吹放弃 HTTPS/TLS，其在现代互联网安全中的基石地位无可替代。HTTPS ...继续阅读 (34)

本文永久链接– https://tonybai.com/2025/05/16/how-rune-came大家好，我是Tony Bai。作为 Gopher，我们每天都在和 rune 打交道。在 Go 语言中，它通常被解释为“一个 Unicode 码点”，官方文档也说引入这个术语是为了“简洁”。但你是否曾好奇，这个略带神秘色彩的词汇，究竟源自何方？仅仅是为了简洁吗？最近，Connor Taffe的一篇精彩博文以及Go语言之父 Rob Pike 的亲自确认，为我们揭开了一段跨越三十余年，从 Plan 9 操作系统到 UTF-8 编码诞生，再到 Go 语言的历史传奇。今天，就让我们一起，深入 rune 背后的故事。一句“简洁”，一段 Plan 9 往事Connor文章中引用的Adam Pritchard的关于限制字符串长度的文章中提到：“请注意，在 Go 中，Unicode 码点通常被称为‘rune’。（Go 似乎是为了简洁而引入了这个术语。）” 而 Go 官方博客《Strings, bytes, runes, and characters in Go》也说：“‘Code point’有点拗口，所以 Go 引入了一个更短的术语：rune。”然而，真相远不止于此。Rob Pike 最近在 Bluesky 上澄清(如上图)，rune 这个词实际上是Ken Thompson在一次为 ...继续阅读 (56)

本文永久链接– https://tonybai.com/2025/05/15/go-json-v2大家好，我是Tony Bai。Go 语言标准库中的 encoding/json 包，无疑是我们日常开发中使用频率最高的包之一。它为 Go 社区服务了十多年，几乎无处不在。但与此同时，它也因一些历史遗留的 API 缺陷、行为不一致以及在某些场景下的性能瓶颈而受到过不少讨论和批评。社区中甚至涌现出像Sonic、go-json、easyjson 等一系列高性能的第三方 JSON 库作为替代。令人兴奋的是，Go 官方团队终于开始着手对 encoding/json 进行一次意义深远的升级——这就是encoding/json/v2的由来。虽然json/v2 尚未正式发布，但其核心代码已经合并到 Go 的开发分支，并可以通过一个实验性特性标志GOEXPERIMENT=jsonv2来提前体验！今天，我就来手把手带大家玩转这个实验性特性，通过官方提供的 gotip 工具，亲自动手体验一下 Go 下一代 JSON 库到底带来了哪些令人期待的改进，特别是在行为正确性和性能方面。背景回顾：为何需要 json/v2？—— encoding/json (v1) 的“四宗罪”在深入实践之前，我们有必要回顾一下 encoding/json (v1) 长期以来积累的一些核心痛点。这些痛点也是催生 json/ ...继续阅读 (43)