本文永久链接 – https://tonybai.com/2025/07/12/insanely-productive-in-go 大家好，我是Tony Bai。 在软件开发的世界里，我们总被灌输一种观念：选项越多，工具越强，生产力就越高。于是，我们追求功能最全的框架、最灵活的配置、以及最新潮的库。 但最近，在 Reddit 的 r/golang 社区，一篇名为《我感觉用 Go 的效率高得离谱》(I feel insanely productive in Go) 的帖子引发了近百条热议。一位曾坚信 TypeScript 和 Python 是“快语言”的开发者，在亲手尝试 Go 之后，发出了“真香”的感叹。 他发现，之前在 Node.js 生态中，光是技术选型——选择哪个运行时 (Bun? Deno?)、哪个 Web 框架 (Express? Fastify?)、哪个 ORM (Prisma? Drizzle?)——就足以耗费他整整一周的时间。他称之为“分析瘫痪” (Analysis Paralysis)。 而在 Go 中，他一天之内就搭建起了项目，开始编写业务逻辑。 这个故事并非孤例，它触动了无数从其他语言生态“迁徙”而来的开发者的心弦。它揭示了 Go 语言一个常常被误解，却又极其强大的超能力：正是那些看似“无聊”的、更少的选项，才赋予了我们惊人的生产力。 告别“分析瘫痪”：Go 的“默认路径”之力 为什么选项更少反而更快？因为 Go 的设计哲学从一开始就在极力避免“分析瘫痪”，为开发者提供一条清晰、低阻力的“默认路径”。 1. 强大的标准库：你的第一选择，也是最好的选择 Reddit 上的高赞评论一针见血：“在 Go [...]
本文永久链接 – https://tonybai.com/2025/07/11/net-http-pprof-v2 大家好，我是Tony Bai。 Go 语言的性能诊断利器 net/http/pprof 即将迎来一次意义深远的变革。一项编号为 #74544 的新提案建议引入一个全新的 net/http/pprof/v2 包，旨在从根本上解决当前版本因“默认注册”行为带来的安全隐患。该提案不仅重塑了 pprof 端点的注册方式，还计划引入对 Go 1.25 飞行记录器（Flight Recorder）的支持、动态 CPU 采样率控制等一系列新功能。本文将深入解读该提案的核心内容、API 变化及其对 Go 开发者生态的潜在影响。 背景：net/http/pprof 的光环与隐忧 net/http/pprof 包是 Go 生产环境调试的基石，拥有超过 31,000 个公开包引用： 开发者只需匿名导入 _ “net/http/pprof”，即可在 DefaultServeMux 上自动注册 /debug/pprof/ 下的所有诊断端点。这种“零成本”的便利性，在内部服务中广受欢迎。 然而，正是这种“自动注册”的特性，成为了一个严重的安全隐患。对于面向公众的服务，开发者很容易因疏忽而将这些包含敏感运行时数据（如执行追踪、内存堆栈、Goroutine 信息等）的端点暴露在公网上，造成严重的数据泄露风险。提案作者 mknyszek 指出，许多大型项目都曾因此遭遇安全问题，不得不紧急修复。社区中，如 #46307 和 #42834 等 issue 也早已指出了这一设计缺陷。 此外，当前 net/http/pprof 包的维护也相对滞后，一些来自社区（如 DataDog）的合理功能增强提案（如 #71213、#66679）积压已久。提案认为，正是因为现有包存在根本性问题，导致团队不愿意在其上继续投入，从而阻碍了其发展。 提案核心：net/http/pprof/v2 [...]
本文永久链接 – https://tonybai.com/2025/07/10/stop-building-ai-agents 大家好，我是Tony Bai。 如果你正在开发 AI 应用，你很可能听说过、尝试过，甚至正在挣扎于构建一个“AI Agent”。 我们都看过那些令人心潮澎湃的 Demo：一个 AI Agent 被赋予一个目标，然后它就能自主地规划、调用工具、浏览网页、编写代码，最终完成任务。于是，我们纷纷投身其中，搭建记忆系统、定义工具、编写角色背景……感觉就像在创造一个真正的数字生命，充满了力量和进步感。 但现实往往是残酷的。正如资深 AI 教育者 Hugo Bowne-Anderson 在他那篇引爆讨论的文章《Stop Building AI Agents》中描述的，他曾用 CrewAI 构建了一个“研究小组”：三个 Agent、五个工具，纸面上完美，实践中一塌糊涂。 研究员 Agent 忽略了 70% 的网页抓取工具。 摘要员 Agent 在处理长文档时完全忘记了使用引用工具。 协调员 Agent 在任务不明确时直接“撂挑子不干了”。 这是一个“美丽的计划，以壮观的方式分崩离析”。这个故事听起来熟悉吗？ Hugo 一针见血地指出：问题的根源，可能不是你的实现细节，而是你从一开始就选择去构建一个 Agent。 AI Agent 的真正“魔鬼”：失控的工作流 要理解为什么 Agent 如此脆弱，我们必须先弄清它的定义。一个 LLM 应用通常具备四个特性： 1. 记忆 (Memory): 让 LLM 记住过去的交互。 [...]
本文永久链接 – https://tonybai.com/2025/07/10/mcp-official-go-sdk 大家好，我是Tony Bai。 随着大型语言模型（LLM）的能力边界不断扩展，“function calling”或“tool use”已成为释放其潜力的关键。MCP（Model Context Protocol）正是为此而生，它定义了一套标准的、与模型无关的通信规范，使得任何应用都能以“工具”的形式被 LLM 调用。 长期以来，mcp官方都没有发布go-sdk，Go社区也一直在使用像mark3labs/mcp-go这样的流行的第三方库。直到Google Go团队安排专人协助mcp组织进行了Go SDK的设计。 7月初，该Go SDK正式以modelcontextprotocol/go-sdk仓库的形式对外开源发布，这是Go 语言在这一浪潮中的一个里程碑事件。它的意义远超一个普通的库： 标准化与权威性：作为官方 SDK，它为 Go 开发者提供了与 MCP 规范紧密同步的、最权威的实现。这意味着更少的兼容性问题和更可靠的长期维护。 Go 语言哲学：该 SDK 的设计充满了 Go 的味道——简洁、高效、强类型和高并发。它鼓励开发者编写惯用的 Go 代码，而不是将其他语言的范式生搬硬套过来。 生态系统的基石：官方 SDK 的出现，将极大地促进 Go AI 生态的繁荣。开发者可以基于这个稳定的基石，构建出更复杂、更健壮的上层应用、框架和平台。 简而言之，它不仅仅是一个工具，更是 Go 语言与 AI 模型世界之间的一座标准化桥梁。 MCP 服务架构：多种通信模式 MCP 协议设计了灵活的通信方式，以适应不同的部署场景。官方 Go SDK 对此提供了出色的支持。主要包括以下几种类型： 标准输入/输出 (Stdio)：这是最简单的模式，客户端通过启动一个子进程（MCP Server），并通过其 stdin 和 [...]
本文永久链接 – https://tonybai.com/2025/07/09/gemini-cli-starting-guide 大家好，我是Tony Bai。 在软件开发的历史长河中，我们与机器的交互界面经历了一场有趣的轮回。 曾几何时，发光的绿色字符在黑色屏幕上跳动，命令行是我们掌控一切的神圣权杖。从编辑器（Vim/Emacs）到编译器，再到版本控制，整个世界都安然地存在于终端的心跳之中。 随后，图形用户界面（GUI）带来了集成开发环境（IDE）的黄金时代。Borland、Visual Studio、Eclipse、JetBrains… 我们将一切都“集成”到了一个窗口里，享受着点击、拖拽和可视化调试带来的便利。命令行似乎一度退居次席，成了执行零散脚本的“后台工具”。 而今天，当我们以为 VS Code 这样轻快、插件丰富的编辑器已经统一江湖时，一股强劲的“复古之风”正悄然刮起。但这一次，它并非简单的怀旧，而是一场由 AI 驱动的、向命令行的“伟大回归”。 为什么是现在？ 因为 AI 的出现，再次打破了 IDE 创造的“完美闭环”。我们发现自己又一次陷入了新的“工作流摩擦”：我们的代码在一个窗口，而我们的 AI “外脑”（ChatGPT/Gemini Web）在另一个窗口。我们成了上下文的搬运工，在复制粘贴中消耗着宝贵的专注力。 IDE 插件虽有所缓解，但它们更像是被“关在笼子里”的 AI，能力受限于 IDE 提供的 API。它们无法真正理解你的整个系统环境，无法为你执行一条 docker build 命令，更无法调用你私有的测试脚本。 我们需要的，不仅仅是一个会写代码的 AI。我们需要一个能理解我们整个工作流，并能动手执行的 AI。敏锐的开发者和 AI 公司都已意识到，下一个效率的爆发点，不在 GUI，而在那片最经典、最高效的战场——命令行。 这，正是这场“命令行革命”的核心。 于是，一个全新的物种 “命令行AI智能体 (Command-Line AI Agent)” 开始涌现。OpenAI Codex、Claude Code等拥有强大能力的商业公司背书的各类智能体脚本便像雨后春笋般出现。而在这一新兴的赛道上，Google也携其 Gemini CLI，给出了一个与众不同的答案。它更侧重于工作流自动化 (Workflow Automation)。更具吸引力的是，通过个人 Google 账户认证，你就能享受到慷慨的免费使用额度，这极大地降低了每一位开发者体验这场命令行革命的门槛。 [...]
本文永久链接 – https://tonybai.com/2025/07/08/typed-struct-tags 大家好，我是Tony Bai。 Go 语言的结构体标签（Struct Tag）自诞生以来，一直是其强大反射能力的重要组成部分，广泛应用于 encoding/json、ORM、配置管理等领域。然而，它也一直是一个“美丽的缺憾”：这些标签本质上是无类型的字符串，依赖于各种“微语言”和“纳米语言”的脆弱约定，缺乏编译期检查，容易因拼写错误或格式问题导致运行时bug。现在，一个旨在彻底改变这一现状的重量级提案——#74472: Typed struct tags——正式进入了社区视野。该提案由 @Merovius 提出，建议在现有字符串标签之外，引入类型化的、编译期检查的结构体标签，一旦落地（虽然短期内不大可能，甚至可能被declined）有望将 Go 的静态类型安全优势延伸至元数据定义领域。在这篇文章中，我们就来简单解读一下这份提案。 现状之痛：从 mini-language 到 pico-language 的脆弱链条 当前的 struct tag 是一个由开发者和库作者共同维护的“社会契约”。reflect 包定义了其顶层语法为键值对（如 key1:”value1″ key2:”value2″ ），而每个库（如 encoding/json）则在各自的 value 中定义了更细分的微语言（如 ,omitempty、,string 等）。更有甚者，某些选项（如 json 的 format）又会引入自己的“纳米语言”（如 format:RFC3339 vs format:’2006-01-02′），这种层层嵌套的自定义语法带来了诸多问题： 缺乏编译期安全： 任何拼写错误、格式错误（如忘记引号）都无法在编译时被发现。开发者只能在运行时通过测试或实际运行失败来定位问题，增加了调试成本。 增加了认知负担： 开发者需要记忆不同库、不同选项的各种微语法规则，容易混淆。 运行时开销： 这些字符串标签需要在运行时被解析，带来了不必要的性能开销和实现复杂性。 命名空间冲突： 标签的键（如 json, yaml）是全局的，没有命名空间隔离。不同第三方库可能使用相同的键但定义完全不同的语法，存在冲突风险。 encoding/json 的 format 选项就是一个典型例子，它要求用户根据格式是预定义常量还是自定义布局字符串，来决定是否使用单引号，这种微妙的语法差异极易出错。 提案核心：引入类型化的常量表达式作为标签 [...]
本文永久链接 – https://tonybai.com/2025/07/07/go-module-supply-chain-attack-case 大家好，我是Tony Bai。 最近，GitLab的安全研究团队披露了一起极其巧妙的供应链攻击，目标直指 Go 社区中一个流行的 MongoDB 模块。这个案例本身已经足够令人警醒，但如果我们拨开攻击手法的层层迷雾，会发现其背后暴露出的，可能是整个开源生态，包括我们所依赖的 Go Modules，一个根本性的、与生俱来的脆弱性。 这个脆弱性，可以概括为六个字：“先发布，后审核”。 而 GitLab 之所以能精准捕获这次攻击，恰恰是因为他们启用了一套新式武器——一个由 AI 辅助的自动化“猎手”。这起“捕猎”行动，就像一支精准的探针，刺中了 Go 模块生态的“阿喀琉斯之踵”。 AI 安全哨兵：新一代的“猎手” 在软件供应链这个庞大的“草料堆”里寻找一根“毒针”，向来是一项艰巨的任务。而 GitLab 这次能成功，得益于他们新开发的自动化检测系统。这个系统并非单一工具，而是一套多层协作的防御体系： 传统方法打底： 系统首先会用传统但有效的方法进行海量筛选。比如，通过自动化拼写错误检测，寻找那些与热门包名字极其相似的可疑模块；通过语义代码分析，标记出那些包含网络请求、命令执行等高危行为的代码。 AI 智能初筛： 这才是真正的“游戏改变者”。当传统方法标记出成千上万个可疑包后，让安全专家逐一排查是不现实的。此时，一个大型语言模型 (LLM) 会介入，扮演“AI 安全哨兵”的角色。 它会对可疑代码进行智能的初始分析，凭借其对代码模式和意图的理解，帮助人类专家： 快速过滤误报： 排除那些虽然有网络请求但行为正常的代码。 识别复杂载荷： 看穿那些通过多层下载来隐藏最终目的的攻击手法。 检测代码混淆： 发现那些试图掩盖真实意图的混淆技巧。 正是这个强大的“猎手”，将我们的目光引向了这次攻击本身。 攻击剖析：当“i”多了一个 现在，让我们来看看被这位“AI 哨兵”揪出来的攻击，到底有多么狡猾。 攻击的目标是流行的 MongoDB Go 驱动 github.com/qiniu/qmgo。这是一个被广泛使用的模块，拥有良好的声誉。 攻击者采取了经典的“拼写错误攻击 (Typosquatting)”，注册了一个极其相似的 GitHub 用户名，并发布了同名的恶意模块： * 合法模块： [...]
本文永久链接 – https://tonybai.com/2025/07/05/agentic-coding-is-the-future 大家好，我是Tony Bai。 软件开发的范式正在经历一场深刻的变革。从 GitHub Copilot 的惊艳亮相，到各种IDE中集成的代码生成功能，我们已经习惯了 AI 在编码过程中的“自动补全”。但这仅仅是序幕。如今，一种更强大、更具颠覆性的模式正在兴起，它就是——Agentic Coding (智能体驱动编码)。 最近，Flask 和 Jinja2 等知名开源项目的作者 Armin Ronacher 分享了他近几个月沉浸式体验 Agentic Coding 的感受。他认为，这开启了人机协作编程的新篇章，带来了前所未有的生产力飞跃。 Agentic Coding 不再是简单的代码提示，而是开发者与 AI Agent 之间的实时协作 (real time collaboration)。它预示着软件开发的未来，一个我们都应该主动了解和拥抱的未来。 超越“自动补全”：Agentic Coding 是什么？ 要理解 Agentic Coding 的变革性，首先要明白它与我们熟悉的“自动补全”工具的本质区别。如果说 Copilot 是你的“智能导航仪”，那么编码 Agent 就是你的“编程搭档”。它能够： 理解和分解复杂任务： 将一个宏大的目标（如“为这个项目添加用户认证功能”）分解为一系列可执行的子任务。 自主使用工具链： 像人类开发者一样，运行编译器 (go build)、测试框架 (go test)、linter、formatter 等。 与开发环境深度交互： 直接创建、修改、删除文件；与 Git [...]
本文永久链接 – https://tonybai.com/2025/07/05/go-is-8020-language 大家好，我是Tony Bai。 如果你写了一段时间的 Go，你可能会有一种独特的感觉。一方面，它简洁、高效、可靠；另一方面，你又会时常觉得它“缺少”了点什么——没有其他语言里那些功能强大、眼花缭乱的特性。 有人因此热爱 Go，有人因此“憎恨” Go。但这种“爱”与“恨”的背后，其实都指向了 Go 语言一个最核心、也最常被误解的设计哲学。最近，一篇精彩的博文《Go is 80/20 language》用一个简单而强大的心智模型，完美地诠释了这一切。 这个模型就是——Go 是一门“80/20”语言。 它旨在用 20% 的复杂度，提供 80% 的实用功能。 正如 Go 语言的创造者之一 Rob Pike 所言：“没人否认 87% 的功能比 80% 好，但问题是，那额外的 7% 功能，往往需要付出 36% 的额外工作。” 这“额外的工作”，不仅是语言实现者的负担，更是我们每一个使用者的隐性成本。 Go 的 80/20 设计实例 让我们通过几个具体的例子，来感受 Go 如何将“80/20 法则”贯彻到底。 1. 并发：Goroutines vs. C#/Rust Async Go 的并发模型极其简单：一个 go 关键字，加上用于通信的 channel。相比于 [...]
本文永久链接 – https://tonybai.com/2025/07/04/slm-is-the-future-of-agentic-ai 大家好，我是Tony Bai。 在 AI 的世界里，“越大越好”似乎已经成为一种颠扑不破的信仰。我们见证了参数量从数十亿飙升至万亿，也习惯了将最强大的通用大语言模型（LLM）视为驱动一切 AI 应用的核心引擎。 然而，就在这股追逐“巨无霸”模型的浪潮之巅，全球 AI 硬件的领导者 NVIDIA，其研究部门却发表了一篇重磅论文，提出了一个看似反直觉，却可能重塑行业的颠覆性观点： AI Agent 的未来，不属于大模型，而属于小模型 (Small Language Models, SLM)。 这不仅仅是一次技术路线的争鸣，更可能预示着 AI Agent 领域一次深刻的架构范式革命。 现状：“大模型单体”的困境 首先，让我们看看当前大多数 AI Agent 的工作模式：它们的核心通常依赖于对少数几个通用 LLM（如 GPT-o3、Claude 4、gemini 2.5 pro 等）的 API 调用。这个 LLM 就像一个无所不能的大脑，负责理解用户意图、进行推理、调用工具、生成代码等所有智能任务。 这种架构虽然在初期能快速验证想法，但其弊端也日益凸显： * 成本高昂： 每一次 API 调用都在燃烧真金白银。 * 延迟不可控： 依赖中心化的云服务，难以满足实时性要求。 * 功能浪费： 大多数 Agent 子任务（如格式转换、意图识别）其实非常简单、重复，用一个“通才” LLM [...]
本文永久链接 – https://tonybai.com/2025/07/04/everything-i-did-to-become-an-expert-in-golang 大家好，我是Tony Bai。 你是否也有过这样的时刻？ 你已经用 Go 写了不少代码，项目也能跑起来，但内心深处总有一种挥之不去的“别扭感”。你写的 Go 代码，看起来更像是“带有 Go 语法的 Java/Python”，充斥着你从旧语言带来的思维习惯。代码或许能工作，但它不优雅，不简洁，总感觉“不对劲”。 最近，Twitch 的一位资深机器学习工程师 Melkey 分享了他从 Go 小白成长为生产级系统开发者的心路历程。他的故事，完美地诠释了如何突破这个瓶颈，完成从“会写”到“写好”Go 的关键一跃。 在这篇文章中，我们就来解读一下这位工程师的Go专家之路，看看从中可以借鉴到哪些有意义的方法。 从“被迫营业”到“感觉不对”的困境 和许多人一样，Melkey 开始学习 Go 并非出于热爱，而是因为工作的“逼迫”。2021年，当他以初级工程师的身份加入 Twitch 时，他还是一个习惯于用 Python 写脚本的“简单小子”，对 Go 一无所知。为了保住这份改变人生的工作，他别无选择，只能硬着头皮学下去。 很快，他熟悉了指针、静态类型和 Go 的基本语法。但问题也随之而来：他感觉自己的 Go 水平停滞不前，写出的代码“干巴巴的”，缺乏神韵。 他只是在完成任务，却丝毫没有感受到这门语言的魅力，更谈不上建立起真正的理解和喜爱。 这正是许多 Gopher，尤其是从其他语言转来的开发者，都会遇到的困境：我们只是在用 Go 的语法，实现其他语言的逻辑。 我们还没有真正进入 Go 的世界。 “顿悟”时刻：《Effective Go》带来的思维重塑 改变发生在 Melkey 偶然读到 Go 官方文档中的一篇文章——《Effective Go》 的那一刻。这篇文章里的几段话，像一道闪电，瞬间击穿了他的迷茫： [...]
本文永久链接 – https://tonybai.com/2025/07/03/meet-the-go-team-2012 大家好，我是Tony Bai。 2012 年，Google I/O 大会的舞台上，一个刚刚发布 1.0 版本的编程语言团队，正襟危坐。他们面对着全球开发者的审视和提问，这其中，就有三位图灵奖得主级别的传奇人物：Ken Thompson、Rob Pike 和 Robert Griesemer。 那一年，Go 1.0 的发布，是一个历史性的里程碑。它意味着一个承诺“向后兼容、稳定可靠”的 Go 语言，正式诞生。 今天，就让我们扮演一次“Go 语言考古学家”，拂去时间的尘埃，回到那个被称为“创世纪”的时刻，重温 Go Team 核心成员们的亲口讲述，探寻这门语言最纯粹的初心和设计哲学。 我们为何创造 Go？—— “厌倦了等待 C++ 编译” 在访谈中，当被问及创造 Go 的初衷时，Rob Pike 给出了一个近乎“玩笑”却又无比真实的答案： “我们厌倦了等待 C++ 的编译。” 他生动地描绘了当时在 Google 内部的日常：为了构建一个巨大的 C++ 二进制文件，团队成员不得不在庞大的计算集群上等待超过一个小时。 更令人抓狂的是失控的依赖管理。Rob Pike 提到，他的同事 Mike Burrows（Chubby 的作者）在一次漫长的编译中发现，一个他从未听说过的、与项目毫无关系的头文件，竟然被重复编译了 37,000 次！ “当你用 ifdef 宏来保护依赖时，你最终得到的就是一个极其稠密的、做了太多无用功的依赖之巢。” [...]
本文永久链接 – https://tonybai.com/2025/07/02/vibe-specs 大家好，我是Tony Bai。 你是否也曾掉入 AI 编程的“氛围陷阱”？ 你坐在 IDE 前，脑海中有一个自以为清晰的任务。你信心满满地打开 AI 助手，给出一个模糊的指令，也就是所谓的“氛围”编程 (Vibe Coding)。结果，AI 像一个过度热情的实习生，还给你一堆看似合理但完全无用的“废话软件”(slop software)，让你陷入无尽的修改和挫败。 如果我告诉你，有一种简单的工作流转变，不仅能解决这个问题，还能将你的功能开发时间减少约 60%，你会不会觉得难以置信？ 最近，一篇名为《Vibe Specs: Vibe Coding That Actually Works》的文章分享的正是这样一个简单却颠覆性的模式。它的核心就是：别再直接让 AI 写代码了！ 在这篇文章中，我们就来看看文章中提到的Vibe Specs究竟是如何提升AI编码的效率和准确性的。 核心解法：拥抱“规范先行” (Spec-First) 文章提出的新范式，彻底颠覆了传统的 AI 编程流程。它将 Prompt -> Code 的直接路径，转变为一个更稳健、更高效的三步曲： LLM -> Spec -> Code 这意味着，与 AI 助手的第一步交互，不是让它写代码，而是让它帮你写一份需求规范 (Specification, Spec)。 这里的精髓在于一个关键的角色转变： 你不再需要费尽心机地写一份完美的 Spec，而是由 AI 扮演“产品经理”或“需求分析师”的角色来“采访”你。 它会主动提问，引导你澄清目标、确定范围、明确核心功能、思考边界条件。而你的工作，仅仅是“批判、调整和澄清”。 [...]
本文永久链接 – https://tonybai.com/2025/07/01/predicting-the-future-of-distributed-systems 大家好，我是Tony Bai。 身处技术浪潮之中，我们每个人或许都曾有过这样的焦虑：新的数据库、新的编程模型、新的 AI 框架层出不穷，我该如何选择？选错了，会不会让团队陷入泥潭，给自己留下难以偿还的技术债？ 最近，特斯拉首席工程师 Colin Breck 在 Craft 2025 大会上做了一场题为《预测分布式系统的未来》的精彩分享。他并没有给出非黑即白的答案，而是提供了一个极其强大的思维武器，来帮助我们拨开迷雾，做出更有效的工程决策。这个武器，就是源自亚马逊创始人 Jeff Bezos 的——“单向门 vs. 双向门”决策框架。 今天，我们就以这个框架为钥匙，跟随 Colin 的思路，去打开分布式系统的未来之门。 决策的“导航仪”：单向门 vs. 双向门 在深入技术细节之前，我们必须先理解这个核心框架。它将决策分为两类： 单向门 (One-Way Door)： 这类决策后果严重，且难以逆转，甚至根本无法回头。一旦你迈进了这扇门，想再出来就要付出巨大的代价。对于“单向门”决策，Bezos 的建议是：必须极其谨慎，放慢速度，召集最相关的人，尽可能多地收集信息再做决定。 双向门 (Two-Way Door)： 这类决策的影响不大，即使做错了，也可以轻松地“退出来”，再选择另一扇门。它的试错成本很低。对于“双向门”决策，应该快速、轻量地由个人或小团队做出，以保持高效率。 这个框架最大的价值在于，它提醒我们警惕一个致命的错误：把一个“单向门”决策，当作“双向门”来草率处理。 这种失误，可能会让你的组织背上沉重的技术包袱，长达数年。 现在，让我们带着这个“导航仪”，去审视 Colin 预测的分布式系统三大趋势。 趋势一：对象存储 —— 充满“双向门”的乐园 Colin 的第一个预测是，对象存储（以 S3 为代表）正在从过去的分析型负载，越来越多地走向事务型和操作型负载，成为下一代数据库和系统的基石。 为什么这个趋势如此确定？因为它为我们创造了大量的“双向门”。 过去，我们选择一个数据库（比如 MySQL），我们的数据、查询方式、扩展模式都被这个“整体”方案深度绑定。想从 MySQL 迁移到 PostgreSQL？这是一项艰巨的任务，更像一扇“单向门”。 而基于对象存储的新架构正在“解体”(Disaggregation) [...]
本文永久链接 – https://tonybai.com/2025/06/29/thinking-parallel-programming 大家好，我是Tony Bai。 在多核处理器已成为标配的今天，并行编程能力几乎是每一位后端工程师的必备技能。Go 语言凭借其简洁的 Goroutine 和 Channel 设计，极大地降低了并发编程的门槛，让我们能相对轻松地驾驭并发。但是，写出“能跑”的并发代码，和写出“优雅、高效、可维护”的并行程序之间，往往还隔着一层思维模式的窗户纸。 今天，我想和大家分享一位计算机科学巨匠——Guy L. Steele Jr.——关于并行编程的深刻洞见。在深入探讨之前，有必要简单介绍一下这位大神：他是 Scheme 语言的共同创造者，Common Lisp 标准的核心定义者，Java 语言设计的关键人物，也是 Sun/Oracle 专门为并行计算设计的 Fortress 语言的领导者。他的见解，源于横跨数十年、从学术到工业的深厚语言设计实践。 他早在多年前（其经典 PPT《How to Think about Parallel Programming—Not!》可以追溯到 2009 年甚至更早）就提出了一些颠覆传统认知，但至今依然闪耀着智慧光芒的核心思想。这些思想，对于我们 Gopher 来说，不啻为并行编程的“第一性原理”，能帮助我们从根本上理解如何更好地设计并行系统。 Steele 的核心论点是什么？一言以蔽之： “编写并行应用程序的最佳方式，就是不必去考虑并行本身。” 这听起来是不是有点反直觉？别急，让我们慢慢拆解 Steele 的智慧。 并行编程的“敌人”：根深蒂固的“累加器思维” Steele 犀利地指出，我们过去几十年在顺序编程中养成的许多习惯，正在成为并行编程的障碍。其中，“累加器 (Accumulators)”模式首当其冲被他判为“BAD”。 什么是累加器模式？简单来说，就是通过一个共享状态（累加器），不断迭代地用新数据去更新这个状态。一个最经典的例子就是顺序求和： // 典型的顺序累加求和 func sumSequential(nums []int) int64 { var total [...]
本文永久链接 – 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 关键字进行声明，验明正身，告诉编译器和所有开发者：“我，某某类，实现了某某接口！” 这是一种名义类型系统（Nominal Typing）的体现，强调“你是谁”。 // Java interface Writer { void write(String data); } class FileWriter implements Writer { // 必须显式声明 @Override public void write(String data) { System.out.println("Writing to file: " + data); } } Go的转变： Go语言则推崇结构化类型系统（Structural Typing），也就是我们常说的“鸭子类型”——“如果一个东西走起来像鸭子，叫起来像鸭子，那么它就是一只鸭子。” 在Go中，一个类型是否实现了一个接口，只看它是否实现了接口所要求的所有方法，无需显式声明。 更重要的是Go社区推崇的理念：“Define interfaces where they [...]
本文永久链接 – 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 让我们能用语句、条件、循环来思考，而不用关心数据如何在寄存器间移动。Fowler 回忆道，他用 Fortran IV 编程时，虽然有诸多限制（如 IF 没有 ELSE，整数变量名必须以 I-N 开头），但这已经是巨大的进步。 现代语言、框架、DSL vs. 早期 HLLs： Ruby、Go、Python 等现代语言，以及各种框架和领域特定语言（DSL），进一步提升了抽象层次。我们现在可以本能地将函数作为数据传递，使用丰富的库和模式，而不用从头编写大量底层代码。 Fowler 指出，尽管这些发展极大地提升了抽象层次和生产力，但它们并没有从根本上改变“编程的性质”。我们仍然是在与机器进行一种“确定性”的对话：给定相同的输入和代码，我们期望得到相同的输出。错误（Bug）也是可复现的。 然而，LLM 的介入，打破了这一基本假设。 Fowler [...]
本文永久链接 – 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 模型/欺诈规则的计数器服务，是一个典型的 I/O 密集型和计算密集型并存的服务，QPS 峰值可达数万。用 Go 实现时，该服务需要大约 20 个 [...]
本文永久链接 – 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）的那些“隐秘角落”，看看它们是如何成为安全陷阱的，并展望一下被寄予厚望的 JSONv2 将如何带来“救赎”。 Go 解析器的“温柔一刀”：那些被忽视的默认行为 Trail of Bits 的文章通过三个核心的攻击场景，向我们展示了 Go 解析器的一些“意外行为”是如何被利用的。让我们聚焦于与 encoding/json (v1 版本，即我们目前广泛使用的版本) 相关的几个关键点： 场景一：非预期的序列化/反序列化 你以为你很好地控制了哪些数据该公开，哪些该保密？但encoding/json [...]
本文永久链接 – 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 生态中的核心痛点。今天，我们就来一起探讨这些引人深思的观点。 注：本文观点主要源自上述博文，并结合我个人的一些思考，希望能为大家带来启发。 Kubernetes 的十年功与过：为何我们需要畅想“2.0”？ 在畅想未来之前，我们必须承认 Kubernetes 取得的巨大成功。它之所以能成为云原生时代的基石，离不开其核心价值： 大规模容器化： 将容器从本地开发环境无缝推向数千台服务器的生产集群，赋予了组织前所未有的灵活性，催生了微服务架构的繁荣。 低维护性： 推动了基础设施从“宠物 (Pets)”到“牛群 (Cattle)”再到“UUID时代”的演进。服务器变得完全可替代，运维模式从手动修复转向“销毁节点，让K8s重组”。 改进的作业系统： 提供了比传统“孤岛式 cron01 服务器”更可靠、更灵活的批处理作业和消息队列任务执行方案。 简化的服务发现与负载均衡： 通过 Service API 提供了稳定的内部 DNS 和 IP，极大地简化了服务间的调用和依赖管理。 然而，正如文章作者所言，“旅程并非没有问题”。“默认值是技术中最强大的力量 (defaults are the most [...]
本文永久链接 – https://tonybai.com/2025/06/20/redmonk-index-2025-jan 大家好，我是Tony Bai。 编程语言的江湖，总是风起云涌，新旧更迭。而 RedMonk 编程语言排行榜，以其独特的视角（结合 GitHub 的代码活跃度和 Stack Overflow 的讨论热度），长期以来都是我们观察这片江湖风向的重要参考。 就在最近，RedMonk发布了其2025年1月的编程语言排行榜。榜单本身波澜不惊，Top 20 的名单几乎与上一期如出一辙，这似乎预示着编程语言领域正进入一个相对“固化”的时期。然而，在这份看似平静的榜单背后，却潜藏着一个巨大的变量，一个足以让 RedMonk 自身都开始反思其排行方法论的“房间里的大象”——那就是 AI 的崛起，及其对 Stack Overflow 数据源的颠覆性冲击。 今天，我们就来解读这份最新的 RedMonk 排行榜，看看 Go 语言在其中表现如何，更重要的是，探讨在 AI 时代，我们该如何看待这类排行榜，以及 Go 语言的未来又将走向何方。 RedMonk 排行榜：方法论回顾与本次看点 在解读具体排名之前，我们有必要简单回顾一下 RedMonk 排行榜的方法论。它并非统计当前“谁用得多”，而是试图通过两个维度的数据来预测语言的未来采用趋势： GitHub 数据： 主要通过 GitHub Archive 拉取数据，分析代码提交中使用的语言，代表了语言在实际项目开发中的活跃度和受开发者青睐的程度。 Stack Overflow 数据： 通过其 Data Explorer 查询，分析特定语言标签下的问题和讨论数量，代表了语言在开发者社区中的关注度和开发者在学习、使用过程中遇到的问题量（间接反映了活跃度）。 RedMonk 强调，榜单的“分层 (Tiering)”比具体的数字名次更重要，因为精确排名本身就存在误差。同时，对于排名靠后的语言，由于数据量较小，其排名的波动性和不确定性会更大。 本次 2025 [...]
本文永久链接 – 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()：是社区呼声的产物，还是多此一举？ 在社区讨论中，有开发者盛赞 errors.Join()，认为它“在需要一次性检查多个不相关错误，或者创建类似伪堆栈跟踪结构以追踪错误传播路径的场景下，是天赐之物，非常棒！” 然而，一些资深 Go 开发者则给出了更审慎的观点：“请不要鼓吹无条件地聚合错误。遵循‘最小惊奇原则’，绝大多数情况下应该在遇到第一个错误时就‘快速失败’。合并错误的场景虽然存在，但合法地罕见。鼓励大家在假设需要合并错误之前，先思考 API 边界及其错误契约。” 这两种截然不同的看法，恰恰反映了 errors.Join() 在实践中可能带来的困惑和需要权衡的场景。 errors.Join() 的“高光时刻”：何时它真的是“天赐之物”？ 尽管“快速失败”是处理错误的主流且通常是正确的策略，但在某些特定场景下，聚合多个错误信息并一次性返回，确实能带来显著的收益。社区讨论中，开发者们也分享了他们认为 errors.Join() 非常适用的场景： 输入验证 (Input [...]
本文永久链接 – https://tonybai.com/2025/06/19/language-design-in-the-era-of-llm 大家好，我是Tony Bai。 大型语言模型 (LLM) 的浪潮正以前所未有的速度和深度席卷软件开发领域。从代码生成、Bug 修复到文档撰写，AI 似乎正成为每一位开发者身边无所不能的“副驾驶”。在这股浪潮中，一个略显“刺耳”但又无法回避的论调开始浮现，正如一篇引人深思的博文《Programming Language Design in the Era of LLMs: A Return to Mediocrity?》中所指出的那样：“一切都更容易用 Python 实现 (Everything is Easier in Python)”——当然，这里指的是在 LLM 的强力辅助下。 这并非危言耸听。文章中展示的图表（来源于论文 “Knowledge Transfer from High-Resource to Low-Resource Programming Languages for Code LLMs“）清晰地揭示了一个趋势：LLM 在那些训练数据量巨大的“高资源”语言（如 Python, JavaScript, Java, C# 等）上，代码生成和任务解决的效能显著高于像 Go、Rust 这样的“低资源”语言： 如果 LLM 能够如此轻松地用 Python（或其他高资源语言）根据自然语言需求生成大部分“胶水代码”甚至核心逻辑，那么我们不禁要问： 精心设计和构建领域特定语言 [...]
本文永久链接 – 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模型的探索与瓶颈。 可伸缩的引擎构建： 全局锁的魔咒如何破解？P（Processor）是如何诞生的？GMP三者如何协作，通过分布式调度和工作窃取实现卓越的伸缩性与效率？ 调度的艺术与匠心： 在高效的基础上，调度器如何追求公平性，避免goroutine饿死？“无限”栈是如何从理念一步步演进为工程现实的？优雅的抢占机制又是如何设计的，以保障系统的响应性与GC的顺畅？ 我们的目标是，通过这种“问题驱动”和“设计者视角”的学习方式： 让你真正理解Go调度器每个设计决策背后的“为什么”。 帮助你将这些原理内化为常识，而非生硬的记忆。 三篇深度探索，为你揭示： 第 1 篇：轻量与并发的初心：Goroutine的设计目标与早期M:N模型的探索 第 2 篇：可伸缩的并发引擎：从分布式调度到M:P:N模型的演进 第 3 篇：调度的艺术与匠心：公平性、动态栈与优雅抢占的实现 无论你是希望在技术深度上更进一步，还是想在面试中展现对Go并发的透彻理解，亦或是对计算机系统底层原理充满好奇，这个微专栏都将是一次不容错过的思想盛宴。 这不仅仅是一次对“Go原理”的学习，更是一次与顶尖工程师设计思想的碰撞与共鸣。 准备好成为Go调度器设计过程的“参与者”了吗？扫下方二维码订阅，让我们一起，拨开并发调度的层层迷雾，探寻其核心的艺术与智慧。 更多有关Go、AI以及云原生的深度微专栏，请点击【微专栏】合集选择订阅。 商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。 © 2025, bigwhite. 版权所有.
本文永久链接 – https://tonybai.com/2025/06/17/rider-elephant-arch 大家好，我是Tony Bai。 在软件架构的江湖里，关于“微服务”与“单体”的论战，几乎从未停歇。一方推崇微服务的灵活性、可扩展性和独立部署，另一方则坚守单体的简洁性、低通信开销和易于本地调试。近年来，我们甚至看到像亚马逊 Prime Video 这样重量级的玩家，也公开分享了其从微服务“回归”到某种形式的单体（或者说更粗粒度的服务）的实践，引发了业界新一轮的思考。 这不禁让我们反问：微服务与单体，真的就是非此即彼的“二元对立”吗？ 最近，国外一家名为DealGate公司的一篇文章《Introducing the Rider and Elephant Software Architecture》，提出了一种他们称之为“骑手与大象”的架构模式，试图在这场看似无解的争论中，找到一条务实的中间道路。这种模式不仅在他们的实践中取得了显著成效，其背后的设计哲学和对技术选型的思考，也颇具启发意义。 “骑手与大象”：一个古老隐喻的现代架构演绎 DealGate 将其架构模式命名为“骑手与大象”，其灵感来源于心理学中的一个经典比喻：人类的思维由两部分组成——理性的“骑手”（对应我们发达的前额叶皮层，负责规划、分析和决策）和感性的、更强大的“大象”（对应我们原始的、更底层的“蜥蜴脑”或“穴居人脑”，驱动着本能和情绪）。骑手虽然可以尝试引导大象，但无法完全控制它；而如果骑手想独自前行，又会发现大象的力量是其无法比拟的。只有当骑手与大象协同合作时，才能发挥出最大的效能。 在 DealGate 的架构中，这个隐喻被巧妙地映射到了技术组件上： “大象 (Elephant)”：由 Go语言构建的应用。它不包含任何复杂的业务逻辑，但却承担着所有“脏活累活”——大规模的、高并发的数据处理。在 DealGate 的场景中，这可能意味着在任何时刻都有数万个 goroutine 在处理图像、PDF，抓取数千万级别的网页，并在每个网页上运行数千万次的正则表达式匹配。“大象”的核心职责是：强大、高效、能扛事儿。 “骑手 (Rider)”：由NextJS (Node.js) 构建的应用。它承载了所有的业务逻辑、数据库访问、用户交互等。“骑手”的核心职责是：灵活、敏捷、快速响应业务变化。 缰绳 (Communication)：“骑手”通过 gRPC 来“引导”和控制“大象”，两者之间保持低开销、高效率的通信。 这种架构的核心思想是：将需要极致性能和高并发处理的“重计算”部分（大象），与需要快速迭代和灵活业务逻辑的“轻应用”部分（骑手）进行分离，并让它们通过高效的通信方式协同工作。 为何选择“骑手与大象”？DealGate 的实践与思考 DealGate 之所以采用这种架构，源于他们在实际业务中遇到的挑战和对现有架构模式的反思。 对“微服务 vs 单体”的“虚假二分法”说不：他们认为，单纯地在微服务和单体之间做选择，往往忽略了业务的复杂性和多样性。他们希望能够“have the best of both worlds”（取两者之长）。 Node.js/NextJS 的局限性：尽管 DealGate 的主要应用是用 [...]
本文永久链接 – 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 语言特性：是“防火墙”还是“导火索”？ 社区论坛上的讨论，首先就聚焦在了 Go 语言本身的一些特性上。 显式错误返回 (if err != nil)：万无一失还是“防君子不防小人”？ 有开发者认为，Go 标志性的显式错误返回设计（即函数返回 (value, error)，调用者必须检查 err），本应是避免错误的有力武器。但也有观点指出，这种模式的“简洁性”（或者说，可以通过 _ 忽略错误的便利性）有时反而可能在项目压力大、追求快速上线时，被开发者有意或无意地跳过，导致潜在的错误处理缺失。比如常见的 value, [...]
本文永久链接 – 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的对比) [...]
本文永久链接 – 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”的概念，代之以更详细的描述。这些更多是内部设计文档的完善，对日常 Go 程序的编写并无直接影响，但体现了 Go 语言设计本身的严谨性和持续迭代。兼容性，依然是 Go 坚不可摧的基石。 更详细地说明可以参考我之前的文章《Go 1.25规范大扫除：移除“Core Types”，为更灵活的泛型铺路》。 运行时与编译器：性能与可靠性的“幕后推手” 这一部分是 Go 1.25 带来诸多“无形”强大之处的集中体现，它们直接影响着 Go 程序的运行效率和稳定性。 [...]
本文永久链接 – 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 语言这种看似“朴素”的“简单”，反而能让如此多的开发者直呼过瘾，成为他们心中“YYDS”？ 在这篇文章中，我们就挑出原贴中几个典型的声音，一起来解读一下。 “Grog脑天堂”的呼唤：返璞归真，大道至简 原帖中提到的“Grog brain heaven”，我们可以理解为一种开发者对纯粹、直接、易于理解和掌控的技术的向往。尤其是在经历了那些充满“魔法”、特性繁杂、需要“JVM柔术”才能驾驭的复杂系统和语言的“洗礼”之后，Go 的出现就像一股清流，让人神清气爽。 “Grog” （可以想象成一个崇尚简单直接的原始人）喜欢造东西，不喜欢猜谜。Go 语言恰好满足了“Grog”的核心诉求： 学得快，忘得慢： 关键词少、特殊字符少、概念少。这意味着学习曲线平缓，上手极快，心智负担极低。你不需要记住成百上千的语法糖或复杂的元编程技巧。 [...]
本文永久链接 – 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 和 o3这样强大系统的科学洞察，是“来之不易的”，但它们的影响将极其深远。 一个核心的观察是，AI 正在经历一个“奇迹变成常规，然后成为基本要求”的演进过程。 Altman 生动地描述了这种转变： 我们从惊叹 AI 能生成优美的段落，到开始期待它能创作出整部小说； 从惊叹 AI 能做出拯救生命的医学诊断，到开始期待它能研发出治疗方法； 从惊叹 AI 能创建小型计算机程序，到开始期待它能构建全新的公司。 这种期望值的快速提升和对 AI 能力的迅速适应，正是“奇点”发生方式的体现——曾经的奇迹迅速融入日常，成为我们对技术能力的新基线。 未来的核心驱动力：AI 加速科学进步与生产力飞跃 Altman 强调，AI 将在多方面为世界做出贡献，但其中最为显著的，将是由 AI 驱动的“更快的科学进步”和“大幅提升的生产力”，这将极大地改善人类的生活质量。 “科学进步是整体进步的最大驱动力，” Altman 写道，“思考我们还能拥有多少，是极其令人兴奋的。” 而更具颠覆性的是，AI [...]
本文永久链接 – https://tonybai.com/2025/06/09/go-simd-intrinsics 大家好，我是Tony Bai。 长期以来，在Go语言中追求极致性能的开发者，当遇到需要利用现代 CPU 的 SIMD (Single Instruction, Multiple Data) 能力时，往往不得不求助于手写汇编。这种方式不仅编写和维护困难，还会导致异步抢占失效、阻碍编译器内联优化等问题。现在，这一“不得不”的时代有望终结。 Go 官方团队正式提出了 #73787 提案：在 GOEXPERIMENT 标志下引入架构特定的 SIMD 内置函数。这一里程碑式的提案，旨在为 Go 开发者提供一种无需编写汇编即可利用底层硬件加速能力的方式，预示着 Go 在高性能计算领域将迎来一场深刻的巨变。在这篇文章中，我就和大家一起解读一下这个里程碑式的提案。 两步走战略：从架构特定到可移植 Highway Go 语言的 API 设计一向以简洁和可移植性著称，但 SIMD 操作的本质却是硬件特定且复杂的。不同 CPU 架构（如 amd64, arm64, riscv64 等）支持不同的向量长度、操作指令甚至数据表示方式。如何在高层抽象的简洁性与底层硬件的复杂性之间找到平衡，是 Go SIMD 设计面临的核心挑战。 为此，Go 团队提出了一个清晰的“两步走”战略： 第一步：低级、架构特定的 API 与内置函数 (Low-level, architecture-specific API) 目标： 提供一组与机器指令紧密对应的底层 SIMD 操作。这些操作将作为 [...]
本文永久链接 – https://tonybai.com/2025/06/07/nucleus-embryo 大家好，我是Tony Bai。 最近，一张名为 “Nucleus Embryo” 的神秘图片在开发者圈子里悄然流传，引发了大家会心一笑（可能还带有一丝“我懂的”的复杂表情）。这张图煞有介事地对比了两个假想的“胚胎”——Embryo 1 和 Embryo 2——据称它们在“出厂设置”时，就已预装了不同的“技术基因”。 乍一看，这图表做得还挺像那么回事：有“Autism (自闭症倾向)”、“ADHD (多动症倾向)”、“Gender Dysphoria (性别焦虑倾向)”这些不明觉厉的百分点，还有看似严谨的“IQ (智商)”点数。但定睛一瞧，嘿，这“Language (编程语言)”、“Editor (编辑器)”、“OS (操作系统)”一栏，赫然出现了我们熟悉的 Rust、Go、VS Code (或类似现代IDE)、Neovim (或Vim)、Arch Linux 和 macOS 的 Logo！ 这显然是一张充满网络 Meme 精神的“恶搞图”，将复杂的人类特征与纯粹的技术偏好进行了一番天马行空的“强行配对”。 今天，我们就本着“纯属娱乐，请勿当真”的精神，来趣味解读一下，假如用技术栈来“测人格”，这两个“胚胎”分别代表了哪一款开发者“出厂画像”？而你，又更接近哪一款呢？ (郑重声明：以下解读纯属借助AI进行的基于网络 Meme 的趣味联想和对技术社区刻板印象的调侃，不代表任何科学观点，更不涉及对任何人群的评价或歧视。请大家在这个闲暇周末轻松阅读，切勿对号入座或上纲上线！) Embryo 1 号：“硬核掌控者”画像？ 让我们来看看 Embryo 1 号的“技术基因配置”： Language: Rust Editor: VS Code (或其抽象变体/同类现代IDE) OS: Arch Linux 如果非要给这个配置画个像，它可能散发着一股浓浓的“硬核玩家”和“掌控一切”的气息： [...]
本文永久链接 – 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 这样“丑陋”的路径。 现有的 go-import meta 标签虽然允许自定义导入路径到 VCS 仓库的映射，但在处理子目录模块时存在局限： 直接指定仓库： [...]
本文永久链接 – 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的形态解读：不仅仅是“大仓库” 首先，我们需要明确什么是Monorepo。它并不仅仅是简单地把所有代码都堆放在一个巨大的Git仓库里。一个真正意义上的Monorepo，通常还伴随着统一的构建系统、版本控制策略、代码共享机制以及与之配套的工具链支持，旨在促进大规模代码库的协同开发和管理。 在Go的世界里，Monorepo可以呈现出几种不同的形态： 形态1：单一仓库，单一主模块 这是我们最熟悉的一种“大型Go项目”组织方式。整个代码仓库的根目录下有一个go.mod文件，定义了一个主模块。项目内部通过Go的包（package）机制来组织不同的功能或子系统。 优点： 依赖管理相对简单直接，所有代码共享同一套依赖版本。 缺点： 对于逻辑上可以独立部署或版本化的多个应用/服务，这种方式可能会导致不必要的耦合。一个服务的变更可能需要整个大模块重新构建和测试，灵活性稍差。 形态2：单一仓库，多Go模块 —— 以etcd为例 这种形态更接近我们通常理解的“Go Monorepo”。etcd-io/etcd项目就是一个很好的例子。它的代码仓库顶层有一个go.mod文件，定义了etcd项目的主模块。但更值得关注的是，在其众多的子目录中（例如 client/v3, server/etcdserver/api, raft/raftpb 等），也包含了各自独立的go.mod文件，这些子目录本身也构成了独立的Go模块。 etcd为何采用这种模式？ 独立的版本演进与发布： 像client/v3这样的客户端库，其API稳定性和版本发布节奏可能与etcd服务器本身不同。将其作为独立模块，可以独立打版本标签（如client/v3.5.0），方便外部项目精确依赖特定版本的客户端。 清晰的API边界与可引用性： 子模块化使得每个组件的公共API更加明确。外部项目可以直接go get etcd仓库中的某个子模块，而无需引入整个庞大的etcd主项目。 更细粒度的依赖管理： 每个子模块只声明自己真正需要的依赖，避免了将所有依赖都集中在顶层go.mod中。 那么，一个Repo下有多个Go Module是Monorepo的一种形式吗？ 答案是肯定的。这是一种更结构化、更显式地声明了内部模块边界和依赖关系的Monorepo形式(即便规模较小，内部的模块不多)。它们之间通常通过go.mod中的replace指令（尤其是在本地开发或特定构建场景）或Go 1.18引入的go.work工作区模式来协同工作。比如下面etcd/etcdutl这个子目录下的go.mod就是一个典型的使用replace指令的例子： module go.etcd.io/etcd/etcdutl/v3 go 1.24 toolchain go1.24.3 replace ( go.etcd.io/etcd/api/v3 => ../api go.etcd.io/etcd/client/pkg/v3 [...]
本文永久链接 – 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 [...]
本文永久链接 – 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 在文章开篇就点出了一个关键问题：很多人对 AI 辅助编程的印象，还停留在半年前甚至两年前的水平。他写道：“如果你在6个月前（或者，天哪，两年前用Copilot的时候）尝试使用LLM编码并失败了，那么你并没有在做大多数严肃的LLM辅助编码者正在做的事情”。 那么，现在“严肃的LLM辅助编码者”在做什么呢？Ptacek 强调，他们使用的是 Agent (智能体)。这些 AI Agent 不再仅仅是根据提示生成代码片段让你复制粘贴，它们能够： 自主地在你的代码库中进行探索。 直接创建和修改文件。 运行各种工具， 如编译器、测试框架、linter、formatter [...]
本文永久链接 – 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) 给出了一个经典的例子： func compute(fn func(float64, float64) float64) float64 { return fn(3, 4) } // 当前写法，类型声明重复 var _ = compute(func(a, b float64) float64 { return a + b }) 许多现代语言，如 Scala ((x, [...]
本文永久链接 – https://tonybai.com/2025/05/31/six-smells-in-go 大家好，我是Tony Bai。 在日常的代码审查 (Code Review) 和线上问题复盘中，我经常会遇到一些看似不起眼，却可能埋下巨大隐患的 Go 代码问题。这些“编码坏味道”轻则导致逻辑混乱、性能下降，重则引发数据不一致、系统崩溃，甚至让团队成员在深夜被告警声惊醒，苦不堪言。 今天，我就结合自己团队中的一些“血淋淋”的经验，和大家聊聊那些曾让我（或许也曾让你）头痛不已的 Go 编码坏味道。希望通过这次复盘，我们都能从中吸取教训，写出更健壮、更优雅、更经得起考验的 Go 代码。 坏味道一：异步时序的“迷魂阵”——“我明明更新了，它怎么还是旧的？” 在高并发场景下，为了提升性能，我们经常会使用 goroutine 进行异步操作。但如果对并发操作的原子性和顺序性缺乏正确理解，就很容易掉进异步时序的陷阱。 典型场景：先异步通知，后更新状态 想象一下，我们有一个订单处理系统，当用户支付成功后，需要先异步发送一个通知给营销系统（比如发优惠券），然后再更新订单数据库的状态为“已支付”。 package main import ( "fmt" "sync" "time" ) type Order struct { ID string Status string // "pending", "paid", "notified" } func updateOrderStatusInDB(order *Order, status string) { fmt.Printf("数据库：订单 %s 状态更新为 %s\n", order.ID, status) [...]
本文永久链接 – 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 强制统一代码风格，彻底终结了关于代码格式的“圣战”，减少了团队协作中的摩擦。 强大的工具链 [...]
本文永久链接 – 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)、聚合 (Reduce)、连接 (Concat)、并行处理 (Zip) 等常用功能。 其核心目标是： 提供标准化的迭代器操作工具： 帮助开发者以更声明式的方式处理序列数据。 [...]
本文永久链接 – 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年提出的，旨在为现代服务（尤其是微服务）提供一套简单、一致且以服务为中心的监控指标集。 让我们逐一拆解： R – Rate (请求速率) 它是什么？ 指服务在单位时间内（通常是每秒）处理的请求数量，我们常说的QPS (Queries Per Second) 或RPS (Requests Per Second) 就是它。 为何重要？ 它是服务负载的直接体现。请求速率的异常波动（骤增或骤降）往往预示着潜在的问题，比如突发流量、上游故障、甚至是恶意攻击。同时，它也是容量规划和弹性伸缩策略的重要依据。 关注什么？ 我们不仅要看服务的总请求速率，还应该关注： 按API端点/服务接口划分的速率： 了解哪些接口最繁忙，哪些接口流量异常。 按客户端类型划分的速率： 识别不同调用方的行为模式。 E – Errors (错误率) 它是什么？ 指服务在处理请求时，发生错误的请求所占的百分比，或者单位时间内的错误请求总数。在HTTP服务中，我们通常重点关注服务器端错误，即HTTP状态码为5xx的请求。 [...]
本文永久链接 – 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 建议大家也都看一下。 我是 Cameron，我是 Google Go 编程语言的产品负责人。我是 Marc，我负责 Go [...]
本文永久链接 – 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 设计中所追求的“Go 境界”。 API 设计的“初心”：Go 团队为 [...]
本文永久链接 – https://tonybai.com/2025/05/22/go-mod-ignore-directive 大家好，我是Tony Bai。 在现代软件开发中，项目往往包含多种语言和技术栈。例如，一个典型的 Web 应用可能同时包含 Go 后端代码、JavaScript/TypeScript 前端代码（及其庞大的 node_modules 依赖目录）、由 Bazel 等构建系统生成的中间目录，以及其他各种配置文件和资源文件。 对于这类项目，Go 开发者经常面临以下挑战： 工具执行缓慢： 当使用 ./… 通配符执行 go list, go test, go vet 等命令时，Go 工具会遍历项目下的所有目录，包括那些与 Go 无关但文件数量巨大的目录（如 node_modules 可能包含数十万文件）。这会导致命令执行时间远超预期。 gopls 资源消耗过高： Go 语言服务器 gopls 在分析项目时，也可能因扫描这些无关目录而消耗大量 CPU 和内存资源，影响 IDE 的响应速度和开发体验。 go mod tidy 行为困扰： 如果被忽略的目录中意外包含了 Go 文件（例如某些 npm 包中携带的示例 Go 代码），go mod [...]
本文永久链接 – 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 的核心价值在于提升软件供应链的透明度和可管理性，从而增强安全性： 透明度与可追溯性： 清晰展示软件由哪些“零件”（开源库、第三方组件、内部模块等）组装而成，包括直接依赖和传递依赖，让软件的构成不再是“黑盒”。 高效的漏洞管理： 当某个组件爆出新的安全漏洞时，通过 SBOM 可以快速定位所有受影响的软件产品，及时采取修复或缓解措施，大大缩短应急响应时间。 许可证合规性审计： 准确识别所有组件的开源许可证类型，确保符合合规要求，避免潜在的法律风险。 供应链风险评估： 了解组件的来源、版本、维护状态等信息，有助于评估整个软件供应链的潜在风险。 提升软件质量与可信度： 向客户和合作伙伴提供 SBOM，能够证明你对软件安全和质量的重视，建立信任。 可以说，SBOM 是构筑现代软件供应链安全防线的基石。 SBOM 标准巡礼：SPDX、CycloneDX、SWID 与 DSDX 要让 SBOM [...]
本文永久链接 – 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, [...]
本文永久链接 – https://tonybai.com/2025/05/20/post-quantum-cryptography-in-go 大家好，我是 Tony Bai。 在我们享受数字时代便利的同时，信息安全始终是悬在我们头顶的达摩克利斯之剑。而这把剑，正面临着来自未来的一个巨大挑战——量子计算机。一旦实用化的大规模量子计算机问世，我们当前广泛依赖的许多经典密码体系（如 RSA、椭圆曲线密码 ECC）可能在瞬间土崩瓦解。 这不是科幻电影，而是密码学界和全球科技巨头都在严肃对待的现实威胁。正因如此，“后量子密码学” (Post-Quantum Cryptography, 以下简称PQC) 应运而生，旨在研发能够抵御量子计算机攻击的新一代密码算法。 作为 Go 开发者，我们或许觉得量子计算机还很遥远，但“现在记录数据，未来量子破解”的风险已然存在。更重要的是，Go 语言作为一门以简洁、高效和安全著称的现代编程语言，其核心团队早已在为这个“后量子时代”积极布局。随着 Go 1.24 的发布，这一布局取得了实质性的进展：备受期待的 crypto/mlkem 包正式加入标准库！ 那么，PQC 究竟是什么？crypto/mlkem 包为我们带来了什么？Go 语言在 PQC 的浪潮中又将扮演怎样的角色？今天，就让我们一起“未雨绸缪”，深入了解 PQC 及其在 Go 中的最新进展。 量子风暴将至：为何我们需要 PQC？ 想象一下，你用 RSA 加密了公司的核心商业机密，或者用 ECDSA 签名了重要的合同。这些操作的安全性，都依赖于经典计算机难以在有效时间内解决某些数学难题（如大数分解、离散对数）。 然而，量子计算机一旦足够强大，Shor 算法就能在多项式时间内攻破这些难题。这意味着： 加密通讯不再私密： HTTPS、VPN 等都可能被破解。 数字签名不再可信： 软件更新、代码签名、身份认证都可能被伪造。 历史数据面临风险： 黑客现在就可以截获并存储加密数据，等待未来用量子计算机解密。对于需要长期保密的医疗记录、金融数据、国家机密等，这无疑是巨大威胁。 这就是我们迫切需要 PQC 的原因：寻找并标准化那些即使是量子计算机也难以破解的新密码算法。 PQC 的曙光：NIST 标准化与主流算法 [...]
本文永久链接 – 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 数据的函数。” 这番话点出了一个残酷的现实：即使是看似轻量级的原子操作，在多核“混战”中也可能成为性能的阿喀琉斯之踵。那么，这背后的深层原因是什么？Go 社区又在如何探索解决之道呢？今天，我们就来深入剖析这个问题，并解读 Go 项目 issue 中几个重要的相关提案，同时看看社区是如何先行一步尝试解决这类问题的。 原子操作为何在高并发多核下“失速”？sync.RWMutex 的痛点 要理解原子操作的瓶颈，我们需要潜入到 CPU 缓存的微观世界。现代多核 CPU 为了加速内存访问，都配备了多级缓存（L1, L2, [...]
本文永久链接 – https://tonybai.com/2025/05/17/java-at-30 大家好，我是Tony Bai。我的极客时间《Go进阶课》专栏已经上线，欢迎大家点击链接订阅学习，我们一起在Go语言的道路上共同精进！ Go语言自开源以来，已走过十多个年头。从最初备受瞩目的“Google语言”，到如今在云原生、微服务领域独当一面，Go 凭借其简洁、高效与强大的并发能力，赢得了全球开发者的青睐，正从一个朝气蓬勃的少年”迈向更加成熟稳健的“壮年”。 然而，“成长的烦恼”也随之而来：生态如何持续繁荣？语言如何在保持核心优势与满足新兴需求之间取得平衡？如何应对一波又一波的技术浪潮冲击？ 恰逢 Java 语言诞生 30 周年，The New Stack 对 Java 之父 James Gosling 进行了一次深度访谈。我刚接触 Java 时，它才发布 1.5 版本（Tiger），一晃近 20 年，Java 依然是全球最重要的语言之一。这位编程语言界的“老大哥”和它的创造者，其“长寿秘诀”无疑能为“风华正茂”的 Go 语言带来诸多启示。 Gosling 在访谈中分享了 Java 长盛不衰的关键，我提炼了几点，希望能为Go的未来之路提供一些借鉴与思考。 秘诀一：【解决真实问题，而非追逐时髦】—— Go 的初心与未来挑战 Java 的经验： James Gosling 强调：“Java 从不追求时髦，始终专注于有效解决问题，帮助工程师完成工作。” 这份对实用主义的坚守，是 Java 能够穿越多个技术周期的基石。 Go 的启示与思考： Go 语言的诞生，正是为了解决当时 C++ 开发的复杂性、Python 等脚本语言的性能瓶颈以及多核时代并发编程的困境。它以大道至简的哲学，直击痛点，迅速在云原生、分布式系统等领域找到了自己的核心价值。 如今，Go 已走过开源的第一个十年，生态日渐成熟。面对 [...]
本文永久链接 – 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 的“能源账单”：开销源自何方？ 要估算节省的电量，首先得理解 HTTPS/TLS 的主要开销在哪里。这些开销主要体现在两个方面：计算开销和数据传输开销。 计算开销 (CPU 的额外负担) TLS 握手阶段： 这是计算密集型操作的重灾区。 非对称加密/密钥交换： 如 RSA、Diffie-Hellman 或 ECC (椭圆曲线加密)，用于安全地协商后续通信所用的对称密钥。密钥长度的增加，使得这些运算的计算量呈指数级或更高阶的增长。 例如，一个 RSA 2048 位操作的计算量远超 1024 位。 证书验证： 客户端需要验证服务器证书链的有效性，这涉及到一系列的数字签名验证操作，同样消耗 CPU 资源。 对称密钥生成与哈希计算： 用于生成会话密钥、消息认证码 (MAC) 等。 数据传输阶段： 对称加解密： 建立连接后，所有应用数据的传输都需要经过对称加密算法（如 [...]
您可以订阅此RSS以获取更多信息