本文永久链接 – https://tonybai.com/2025/12/15/go-language-anti-patterns-10-donts

大家好，我是Tony Bai。

“有哪些‘不要做’的教训，是你花了好几年才学会的？”

近日，在 r/golang 社区，这个简单的问题，引爆了一场关于 Go 语言“反模式”与“最佳实践”的集体反思。帖子下数百条评论，汇集了无数 Gopher 在真实项目中用“血与泪”换来的宝贵经验。这些教训，往往不是关于某个高深的算法，而是关于那些看似“理所当然”，却在不经意间为代码埋下地雷的日常习惯。

这篇文章，正是对这场集体智慧的一次系统性梳理。我们从中提炼出 10 条最核心的“不要做”法则，它们如同一份“避坑指南”，能帮助你绕开那些最常见的陷阱，更快地从一名“会写 Go 的程序员”，成长为一名“懂 Go 的工程师”。

不要过度封装包

Don’t overpackage things

初学者往往有一种冲动，想把代码组织成“语义化”的、层层嵌套的包结构。internal/models, internal/services, internal/repositories…… 这种源自其他语言（如 Java）的模式，在 Go 的世界里，往往是一种过早的、不必要的复杂性。

社区忠告：从一个 main.go 文件开始。努力思考，是否真的有必要将代码拆分到多个文件/包中。Go 的包，其主要目的是封装和依赖管理，而不是单纯的文件夹分类。在小型或中型项目中，一个清晰的、扁平的包结构，远比一个复杂的“企业级”目录树更易于维护。

不要滥用 channel 和 goroutine

Don’t just add in channels

并发是 Go 的“名片”，这使得许多开发者（尤其是新手）有一种“锤子心态”——看到任何问题，都想用 goroutine 和 channel 来解决。然而，不必要的并发，是复杂性和 bug 的温床。

社区忠告：

• 先问“是否需要”：你真的需要并发吗？如果不需要在线程间传递消息，你可能根本不需要 channel。一个简单的 sync.WaitGroup 或 sync.Mutex，在很多场景下都比 channel 更简单、更直接。
• 并发不是免费的：Go 让创建 goroutine 变得异常简单，但这并不意味着它是零成本的。过多的 goroutine 会增加调度器的负担，而 channel 的滥用则会使数据流变得难以追踪和调试。

不要盲目追求 DRY

Don’t be zealous about DRY

DRY 是编程的基本原则，但在 Go 的哲学中，它有一个更重要的“上级”——清晰性。为了消除几行重复代码，而引入一个复杂的接口或一个晦涩的辅助函数，往往得不偿失。

社区忠告：“一点点复制，胜过一点点依赖 (a little copy-paste is better than a little dependency)。” 当你发现自己在为了 DRY 而绞尽脑汁时，请停下来问问自己：这份重复，是否真的带来了维护上的痛苦？如果不是，那么接受它，可能是一个更明智的选择。

不要在同一个 PR 中既重构又添加新功能

Don’t refactor and add features in the same PR

在添加一个新功能时，顺手“优化”一下周围的代码，这看起来很高效。但实际上，这会让 Code Review 变得异常痛苦。Reviewer 无法清晰地分辨，哪些改动是为新功能服务的，哪些是纯粹的重构。这不仅增加了审查的难度，也提高了引入新 Bug 的风险。

社区忠告：遵循“童子军军规”——“让营地比你来时更干净”——是好的。但请将它分解为两个独立的、目标明确的 PR：一个只做重构，另一个（基于重构后的代码）只添加新功能。

不要跳过写测试，“就这一次”

Don’t skip writing tests “just this once”

这是所有开发者都曾屈服过的诱惑。“这个改动太小了”、“我百分之百确定它是对的”、“项目赶时间”…… 每一次“就这一次”的妥协，都在为未来的“技术雪崩”添砖加瓦。

社区忠告：将测试视为代码不可分割的一部分。在 Go 中，编写测试是如此简单和自然，以至于没有任何借口可以跳过它。你今天节省下来的 10 分钟，可能会在未来，让你或你的同事，花费数天时间去调试一个本可避免的生产问题。

不要害怕使用 sync.Cond

channel 非常强大，但它并非解决所有并发同步问题的“银弹”。社区中有一种“反 sync”的情绪，认为所有同步都应该用 channel 来完成。

社区忠告：sync.Cond 是一个被低估了的、极其强大的并发原语。当你需要基于某个特定条件来唤醒一个或多个等待的 goroutine 时（例如，一个任务队列的消费者在队列为空时等待），sync.Cond 往往比用 channel 实现的复杂信令机制，要更简单、更高效。不要因为不熟悉，就回避它。

不要返回接口

Returning interfaces. Don’t do it.

在函数签名中返回一个接口，看似遵循了“依赖倒置”的高级原则，甚至觉得这样更“灵活”。但实际上，这往往是一种过早的、有害的抽象。它剥夺了用户访问底层具体类型特有功能的能力，并且如果未来需要添加新方法，接口的变更会极其痛苦。

社区忠告：遵循 Go 的经典谚语：“接收接口，返回结构体 (Accept interfaces, return structs)。”

• 接收接口：让你的函数接收一个只包含其所需最小方法集的接口作为参数。这使得你的函数更容易被测试和复用（你可以传入任何满足该接口的实现，包括 Mock 对象）。
• 返回结构体：让你的函数返回一个具体的类型（通常是指针）。这给了调用者最大的灵活性。

经典范例：

看看标准库中的 os.Open，它返回的是 *os.File（具体结构体），而不是 io.Reader（接口）。
* 为什么这样做？ 因为 *os.File 不仅能读（Read），还能关闭（Close）、获取状态（Stat）、甚至改变权限（Chmod）。
* 灵活性：如果它返回的是接口，用户就无法使用 Chmod 等特有功能了。而返回结构体，用户既可以使用其全部功能，也可以在需要时，轻松地将其赋值给 io.Reader 接口来使用。这就是“返回结构体”带来的自由。

(注：只有当返回的类型是包内私有的、不希望外部直接访问的实现细节时，返回接口才是有意义的，例如 context.WithCancel 返回的是 Context 接口。)

不要过度依赖依赖

Don’t add dependencies without vetting

为了解决一个小问题，而引入一个庞大的、闪亮的第三方库。这在 Node.js 生态中很常见，但在 Go 社区，这通常被视为一种“危险信号”。

社区忠告：

• 先求诸标准库：在引入任何依赖之前，先问问自己：这个问题，标准库真的解决不了吗？
• 审慎评估：如果必须引入依赖，请仔细评估它：它的依赖树有多深？社区是否活跃？维护者是否可靠？一个简单的依赖，可能会为你整个项目，带来潜在的供应链安全风险和维护噩梦。

不要盲从

Don’t do [or not do] something simply because an authoritative voice recommended it

盲目地遵循某个“大神”、某篇“爆款”博客文章、或者某个“权威”推荐的模式，而没有结合自己的具体场景进行批判性思考。

社区忠告：上下文决定一切。YAGNI (You Aren’t Gonna Need It) 是一个好原则，但有时你确实需要提前设计。微服务很好，但有时单体就是最佳选择。没有银弹。最好的实践，是那些在你的团队、你的项目中，被证明行之有效的实践。

不要忘记，代码是给人读的

忘记了代码的最终读者是人类，而不是编译器。编写只有自己能看懂的“聪明”代码，或者忽略文档和注释的重要性。

社区忠告：

• 编写能让你的未来“自已”不会痛骂你的代码。
• 好的设计不是增加，而是保持本质的简单。代码即是负债 (Code is liability)。
• 不要忽视清晰文档的重要性。

小结：在“坑”里成长

这份清单，远非全部。社区的讨论中还充满了诸如“不要用 singleton 来做 mock”、“不要滥用 init 函数”、“不要在疲劳时 Review 代码”等无数宝贵的经验。

它们共同指向了一个核心思想：成为一名优秀的 Go 工程师，其过程不仅仅是学习语言的特性，更是一个不断反思、不断“踩坑”、并从“坑”中总结出属于自己“不要做”清单的修炼过程。希望这份来自社区的集体智慧，能让你在这条路上，走得更稳、也更远。

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

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

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

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

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/12/14/dont-let-ai-put-your-brain-cpu-in-wait

大家好，我是Tony Bai。

先问一个扎心的问题：当你给 ChatGPT、Cursor 或 Claude Code 发送了一个复杂的 Prompt 之后，接下来的 30 秒到 1 分钟里，你在干什么？

我观察过很多开发者，90% 的人是这样的：

双手离开键盘，甚至抱在胸前，眼睛死死盯着屏幕上那个闪烁的光标，看着文字一个字一个字地蹦出来。心里默默念叨：“快点，再快点……”

在计算机科学里，这叫什么？

这叫 I/O 阻塞（Blocking I/O）。

在这个场景里，AI 是那个慢速的 I/O 设备（就像早期的磁带机或机械硬盘），而你——拥有几十亿神经元、算力无法估量的人类大脑（CPU），却因为等待这个 I/O 响应，被迫挂起（WAIT），处于完全闲置的状态。

这不仅仅是时间的浪费，这是算力的极大浪费。

很多开发者抱怨：“AI 有时候太慢了，打断了我的思路。”

但事实的真相可能是：不是 AI 慢，而是你的“调度算法”还停留在单核时代。

职场新分层：单核工作者 vs. 多核工作者

随着 AI 能力的普及，代码生成的质量差距正在缩小。未来的竞争壁垒，将从“你会写什么 Prompt”转移到“你如何管理与 AI 的并发交互”。

这导致了两种工作模式的分化，我们可以通过下面这张 “大脑CPU” 调度时序图来直观对比：

模式 A：单核工作者（同步阻塞）
* 特征： 就像单核 CPU 跑单线程程序。发完指令后，必须盯着屏幕等结果，算力被强行挂起（Wait）。
* 痛点： 图中红色的区域就是被浪费的生命。只要 AI 稍微卡顿，你的工作流就被切断了。

模式 B：多核工作者（异步并发）
* 特征： 就像现代操作系统的分时调度（Time-sharing）。人脑作为 OS Scheduler，维护着多个任务的状态。
* 优势： 图中绿色的区域显示，当 AI 在后台“搬砖”时，你的大脑立刻切换（Switch）到下一个任务（编写 Spec B）。
* 收益： 在 AI 响应延迟短期内无法消除的前提下，模式 B 的产出效率是模式 A 的 2 倍甚至更多。

第一性原理：如何优化大脑的“调度算法”？

既然“多核模式”效率极高，为什么 99% 的人做不到呢？

核心难点在于“上下文切换（Context Switching）”的成本。

做过底层开发的都知道，CPU 在切换线程时，必须执行一个昂贵的操作：Save Context（保存现场）和 Restore Context（恢复现场）。

人脑也是一样，甚至更弱。

根据认知心理学的“米勒定律”，人类的工作记忆（Working Memory，相当于 CPU 的 L1 Cache）容量极小，只有 7±2 个单位。

当你从“编写 Go 后端”切换到“调试 Vue 前端”时，你的 L1 Cache 会瞬间被清空。等你切回来时，你需要重新阅读代码、重新回忆变量名——这个过程就是“冷启动”，极度消耗能量。

所以，要实现高效的“人脑并发调度”，我们不能靠死记硬背，必须利用第一性原理优化我们的交互协议。

上下文卸载 (Context Offloading)

计算机如何解决内存不足的问题？虚拟内存（Swap）。 把不用的数据换出到硬盘里。

我们要模仿这个机制。不要试图在脑子里维持与 AI 的对话状态。

凡是发给 AI 的任务，必须是一个“全量的、自包含的数据包”。在这个数据包里，包含了 AI 完成任务所需的所有背景、约束和目标。

一旦发送出去，你的大脑应当能彻底遗忘（Forget）这个任务，清空 L1 Cache 去处理下一个线程，直到收到“完成”的中断信号。

无状态交互 (Stateless Interaction)

目前的“Chat 模式”是典型的有状态（Stateful）交互。你必须记得上一句说了什么，下一句才能接得上。这是并发的天敌。

高效的调度算法要求我们采用无状态（Stateless）交互。

每一次与 AI 的交互，都应该是一次独立的 API 调用。我不关心你记不记得上下文，我会在这一次指令中把上下文重新传给你。

我们可以用一张系统架构图来理解这种“大脑调度优化”：

结论很明显：

要让大脑 CPU 不阻塞，关键不在于你思考得有多快，而在于你是否拥有一个“外部存储（External RAM）”机制。

你需要一种介质，能够帮你低成本地固化上下文，让你敢于放手（Fire），也方便你随时捡起（Resume）。

那么，在软件工程领域，这种“固化上下文的介质”叫什么呢？

落地实战：Spec 就是你的“外部存储”

答案就是 Spec（规范说明书）。

而这种全新的开发范式，我们称之为 SDD (Spec-Driven Development，规范驱动开发)。

为什么“聊天（Chat）”是并发的天敌？

目前主流的“Chat-based Coding”本质上是同步且有状态的。

你输入：“把这个函数改一下。”
AI 问：“改成啥样？”
你回：“像上次那个一样。”

这就完了。 你的大脑被迫挂载了海量的历史上下文，你必须在线，必须记得“上次”是指哪次。一旦去回个邮件，回来你就断片了。

SDD 如何实现“异步并发”？

在 SDD 工作流中（特别是配合像 Claude Code、Gemini Cli 这样的新一代 CLI 编码智能体工具），交互模式发生了质变：

• Context Offloading（上下文固化）： 你不再在对话框里碎碎念，而是打开一个 Markdown 文件（Spec），把接口定义、业务逻辑、边界条件、甚至测试用例全部写下来。写完的那一刻，你的大脑内存就释放了。
• Stateless Execution（无状态执行）： 你将这个 Spec 文件投喂给 AI。对于 AI 来说，这是一个全量的、自包含的原子任务。它不需要知道你昨天说了什么，它只需要根据这份文档执行。
• Fire and Forget（即发即忘）： 指令发出后，你不需要盯着光标。AI 在后台读文档、写代码、跑测试。你可以立刻切换到下一个 Spec 的编写中。

让我们看下这张 SDD 并发工作流时序图：

Spec，就是你发给后台进程的“异步数据包”。它让你的大脑从“内存条”变成了高效的“调度器”。

写在最后：工具与范式，决定了你的并发量

除了思维的升级，你必须掌握一套支持“异步并发”的开发工具链。

如果你还在用浏览器里的聊天窗口写代码，你依然很难摆脱“I/O 阻塞”。

真正的解法，是构建一套基于 Claude Code/Gemini Cli… 的 SDD 工作流。

这不仅是工具的改变，更是软件工程的回归——从“堆砖头（Coding）”回归到“画图纸（Architecting）”。

• 你可以只做定义者： 你的核心工作不再是纠结 for 循环怎么写，而是编写清晰、严谨的 Spec。
• 让 AI 做实现者： AI 成为你的异步协程。它在后台自动完成实现、修复、测试的闭环。

这才是多核工作者的终极形态：你负责定义世界（Spec），AI 负责构建世界（Code）。

如果你想彻底掌握这套方法论，从“单核等待”进化到“多核并发”，欢迎关注我的极客时间专栏《AI 原生开发工作流实战》。

在这个专栏里，我将带你深入基于工具和新范式的实战：

1. SDD 标准化： 如何编写 AI 一眼就能看懂、执行不出错的高质量 Spec？
2. 工具链配置： 如何配置 Claude Code 等工具，实现“投喂 -> 自动执行 -> 自动审查 -> 自动测试”的流水线？
3. 并发实操： 真实演示如何在 1 小时内，通过并发调度完成传统模式下 4 小时的开发量。

别再盯着光标发呆了。写好 Spec，剩下的交给 AI。 扫描下方卡片，开启你的多核开发之旅。

聊聊你的“并发”状态

你是否也曾陷入过那种“盯着光标发呆”的单核陷阱？在你的日常工作中，你是如何处理AI响应那几十秒的“真空期”的？ 是切屏摸鱼，还是有自己独特的“上下文切换”技巧？

欢迎在评论区分享你的“多核”心得或“阻塞”吐槽！ 让我们一起寻找最高效的人机协作模式。

如果这篇文章让你对AI编程有了全新的认知，别忘了点个【赞】和【在看】，并转发给身边那个还在“单核”工作的朋友！

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

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

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

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

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

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