Python - Tony Bai

本文永久链接 – https://tonybai.com/2025/08/05/go-concurrency-mental-model

大家好，我是Tony Bai。

如果你曾是 Java、C++ 或 Python 阵营的一员，你一定对 synchronized、std::mutex 或 threading.Lock 这些概念驾轻就熟。它们就像我们工具箱里熟悉的锤子，在处理并发问题时，我们总能下意识地拿起它，去“敲定”那些需要保护的共享资源。

然而，当你满怀期待地步入 Go 的世界，准备大展拳脚时，却发现社区和高手们总在谈论一个看似“绕路”的概念——通道 (Channel)。他们反复强调一句如同“咒语”般的箴言：“不要通过共享内存来通信；相反，要通过通信来共享内存。”

这时，困惑便产生了：

“放着简单直接的锁不用，为什么要用看起来更复杂的 Channel？”
“Channel 和 Mutex 到底该在什么场景下选择？有没有一个万能的法则？”
“我用 Go 写的并发程序，为什么总感觉不地道，甚至比我用 Java 写的还容易出错？”

如果你曾有过这些疑问，那么恭喜你，你已经触及了掌握 Go 并发精髓的核心症结。问题不在于 Go 的语法有多难，而在于我们试图用旧的“心智模型”去套用一个全新的并发范式。这就像试图用拉丁语的语法去理解中文的意境，生硬的翻译只会让你离真相越来越远。

这个微专栏，就是为你——一位从其他编程语言阵营走来，希望真正掌握 Go 并发精髓的开发者——量身打造的“心智模型”转变教程。

在这里，我不会枯燥地罗列 API，也不会给你一堆零散的“最佳实践”。我的目标是带你完成一次思维的“破冰”与“重塑”。在这次由三节课组成的“转变之旅”中，我们将一起：

第一课：心智模型转变。 我们将从根源上剖析 Go 并发哲学的不同，通过一个具象的案例，亲身体验从“加锁”思维到“通道通信”思维的转变是多么酣畅淋漓。你将明白，为何 Channel 才是 Go 并发世界的一等公民。
第二课：心智模型实践。 我们会将新的心智模型应用到工业界最常见的并发模式中，并直面、破解“慢消费者”和“任务调度”这两个经典难题。
第三课：心智模型升华。 我们将探讨并发编程中最容易被忽视，也最致命的一环——Goroutine 的生命周期与工程纪律。你将学会如何避免资源泄漏，如何优雅地控制和关闭你的并发程序。

我不是来教你语法的，而是邀请你和我一起，完成一次思维的升级。我希望，当这个微专案结束时，你收获的不仅仅是几个可以复制粘贴的代码模板，而是一种全新的、看待并发问题的视角。你将能够自信地写出简洁、健壮、地道的 Go 并发代码，真正领略到这门语言在设计上的巧思与优雅。

准备好了吗？扫描下方二维码订阅微专栏，让我们一起跳出那片熟悉的“锁”与“等待”的沼泽，正式开启这场 Go 并发心智模型的转变之旅。

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

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

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

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

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

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

AI 正在放大技术选型的风险：为什么我们更应该“选择无聊的技术”

本文永久链接 – https://tonybai.com/2025/08/03/choose-boring-technology

大家好，我是Tony Bai。

大约十年前，Dan McKinley 的一篇经典雄文《选择无聊的技术》（Choose Boring Technology）在工程师圈子里广为流传。它的核心观点简单而深刻：一家公司的“创新代币”（innovation tokens）是有限的，应该用在刀刃上，而不是随意挥霍在那些闪亮但未经证实的新技术上。

“无聊”的技术，比如 Postgres、Python、PHP，它们的优势不在于新潮，而在于其故障模式和能力边界是众所周知的。当系统在凌晨三点崩溃时，你需要的是一个有大量 Stack Overflow 答案可以求助的领域，而不是一片你必须独自开拓的未知“无人区”。

这个原则，在过去十年里，成为了无数资深工程师的技术选型座右铭。然而，十年后的今天，随着 LLMs 和 Agentic AI 编程工具的崛起，业界仍然认为：这个原则不仅没有过时，反而比以往任何时候都更加重要，甚至更加致命。

AI 时代的“诱惑”与“危险”

AI 编程助手带来了一个全新的变数。这个变数既有趣，又极其危险。

这里的“有趣”在于，现代 AI 工具（无论是 Claude 还是 Copilot）已经非常擅长为几乎任何你能想到的技术栈，生成“看起来非常专业”的代码。你给它一个 prompt，让它用最新的 JavaScript 框架、GraphQL federation 和 Kubernetes 来实现一套微服务，它会迅速给你返回一堆代码——这些代码可能遵循了所有社区惯例，命名规范无可挑剔，错误处理看起来也像模像样，甚至，它可能真的能运行。

这就是 AI 的“诱惑”。它让你感觉，掌握任何新技术都不过是弹指一挥间的事。

而“危险”也恰恰源于此。当你在一个你不熟悉的技术领域里使用 AI 时，一个致命的问题出现了：

你根本无法验证，AI 是不是在“一本正经地胡说八道”（bullshitting you）。

我亲眼见过，有工程师接受了 AI 生成的代码，而这些代码里：

使用了早已废弃的 API。
实现了严重的安全反模式。
制造了只有在生产负载下才会暴露的、极其隐蔽的性能问题。

为什么会这样？因为这些代码“看起来是对的”。但它的错误，是深植于技术细节中的，只有真正熟悉这门技术的人才能一眼看穿。

风险的“乘法效应”

过去，我们说选择一门新技术是增加了一个“未知数”。而在 AI 时代，当你将不熟悉的技术与 AI 生成的代码结合时，你不再是简单地增加未知数，而是在乘以未知数。

你不知道这个框架是否是解决你问题的最佳选择；你不知道 AI 的实现是否遵循了最佳实践；你不知道生成的代码中，哪些是无伤大雅的模板，哪些是核心业务逻辑；你更不知道，这套组合拳将会以何种奇特的方式在未来失效。

这已经不是简单的“货物崇拜”（cargo-culting）了，这是指数级的货物崇拜。

注：“货物崇拜”（cargo culting）是一个源自太平洋岛屿的概念，最早用于描述一些岛屿居民对西方物资和技术的崇拜现象。在二战期间，许多西方士兵在这些岛屿上驻扎，带来了大量的物资和现代技术。当地人对这些物品产生了强烈的向往，认为这些物品是神灵的恩赐。

AI 时代的“技术选型第一性原理”

那么，我们该怎么办？答案出奇地简单，它让我们回归到了那个最朴素的原则：

AI 是你所理解技术的“力量倍增器”，却是你不理解技术的“脆弱拐杖”。

当你选择“无聊”的技术，也就是你真正精通的技术时，AI 会变得无比强大。你可以让 Claude 帮你生成 Rails 代码，因为你对 Rails 了如指掌，能轻易发现它何时提出了可疑的建议。你可以让 Copilot 辅助你写 JavaScript，因为你理解这门语言的怪癖，能对它的产出进行事实核查。

在这种模式下，AI 是你的副驾驶，为你处理繁琐的路线，而你始终掌握着方向盘。

给 AI 时代开发者的实践指南

那么，在一个充满 AI 编程助手的世界里，我们该如何应用“选择无聊的技术”这一原则呢？这里有三条黄金法则：

评估新技术时先自问：“如果 AI 为它生成了代码，我有能力审查吗？” 如果答案是否定的，那么这项技术或许不应该用于任何对你而言是任务关键型（mission-critical）的项目。
学习新技术时（当你决定用掉一个“创新代币”时）： 请务必花时间深入理解它，达到能对 AI 的建议进行独立事实核查的程度。不要只是复制、粘贴，然后祈祷好运。
抵制诱惑： 不要把 AI 工具当作一个借口，让你能同时拥抱一门新语言、一个新框架和一套新基础设施。AI 可能会给你一种“我能搞定一切”的错觉，但你无法真正验证其中任何一环。