本文永久链接 – 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/09/30/good-taste-in-software-engineering

大家好，我是Tony Bai。

在软件工程领域，我们习惯于用“技术能力”（Technical Skill）来衡量一位工程师的优劣。他是否精通并发模型？能否写出高性能的代码？对底层原理的理解有多深？这些能力可以通过学习和重复练习来获得，是我们评价体系中的“硬通货”。

然而，github工程师Sean Goedecke在他最新的博文中，提出了一个新的观点：决定工程师成长上限的是“技术品味”（Technical Taste）。他认为，“品味”与“能力”是两个正交的维度。你可以技术能力很强，但品味很差；也可以技术尚在发展，但已具备良好的品味。就像一个美食家，即使自己不会烹饪，也能分辨出食物的好坏。同样，一个有品味的工程师，在能亲手构建一个复杂系统之前，就已经知道自己喜欢什么样的软件。在文章中，他还特意以Go的一些语法特性举例，来诠释什么是工程品味。

在这篇文章中，我们将一起拆解“技术品味”这个看似玄妙的概念，学习如何识别自己和他人身上的“坏品味”（比如对“最佳实践”的盲从），并探索一条培养“好品味”的实践路径，帮助我们Go开发者在日常的权衡与决策中，做出更成熟的选择。

“品味”不是“对错”，而是“价值观”的排序

文章以一个经典的例子开场：for循环 vs. map/filter。

许多来自函数式编程背景的开发者会认为，使用map/filter的代码“看起来更美”，因为它们通常涉及纯函数，易于推理，还能避免一类的迭代器bug。这似乎是一个关乎“正确”与“错误”的技术问题。

然而，Go语言的设计者们，出于“有原则的理由”，并没有在语言核心中原生内置map/filter。在Go中，一个简单的for循环：

• 性能上更易于推理：没有高阶函数调用的开销。
• 更灵活：可以轻松扩展到更复杂的迭代策略（如一次处理两个或多个元素）。

这个分歧的本质是什么？Goedecke一针见血地指出：这不是一个关于技术能力高低的争论，而是一个关于“工程价值观”（Engineering Values）优先级排序的差异。

• 偏爱map/filter的工程师，可能将“表达力”和“数学上的优雅”排在了更高的位置。
• 偏爱for循环的Go语言设计者们，则将“性能透明度”和“实现的直接性”置于首位。

成熟的工程师，能够理解并承认这种差异源于价值观的不同，而非技能的缺失。

什么是工程中的“好品味”？

几乎所有软件工程决策都是一次权衡（tradeoff）。

你很少能在两个选项中找到一个绝对更优的。你总是在不同的工程价值观之间做艰难的取舍，比如在“性能”和“可读性”之间，或者在“开发速度”和“正确性”之间。

不成熟的工程师会固执己见，认为“X永远比Y好”。而成熟的工程师则会评估双方的优劣，并思考：“在当前这个特定的项目中，X的收益是否大于Y的收益？”

因此，Goedecke对“技术品味”给出了一个精辟的定义：

Taste is the ability to adopt the set of engineering values that fit your current project.
(品味，是为当前项目选择一套恰如其分的工程价值观的能力。)

你的个人技术偏好，构成了你的基础“品味”。而“好品味”，则是在这个基础上，根据项目所处的真实环境（团队能力、业务阶段、性能要求、交付压力等），灵活调整你的价值观优先级的能力。

如何识别“坏品味”？—— “最佳实践”的诅咒

“坏品味”最常见的表现形式，就是僵化（inflexibility）。

I will always distrust engineers who justify decisions by saying “it’s best practice”.
(我永远不信任那些用“这是最佳实践”来为决策辩护的工程师。)

没有任何工程决策是在所有情境下的“最佳实践”。

当你听到有人用这个词时，往往意味着他正在将过去某个项目的成功经验（那套当时恰好适用的价值观），僵化地、不加思考地套用到一个全新的问题上。

• 一个在金融科技公司追求“五个九”可用性的工程师，如果将同样的价值观带到一个需要快速迭代验证想法的初创公司，坚持为内部仪表盘构建跨区域部署，那就是“坏品味”。这会让项目变得复杂无比，难以理解，拖慢了产品发布的速度，甚至导致了失去市场的机会。
• 一个习惯于用Ruby元编程“炫技”的开发者，如果在一个追求长期可维护性的Go项目中，滥用reflect来实现类似的动态能力，那也是“坏品味”。

Goedecke用了一个绝妙的比喻：品味差的工程师就像一块坏掉的指南针。在一块特定的磁场里（比如他之前工作的领域），这块坏指南针可能恰好能指向北方，让他看起来非常高效。但一旦环境变化（换了项目或公司），这块指南针就会立刻将团队引向错误的方向。

如何培养“好品味”？—— 拥抱灵活性与真实世界

培养技术能力有明确的路径：读书、练习、看代码。而培养“技术品味”则更为神秘。Goedecke给出的建议是：

1. 涉猎多样化的项目：在不同类型、不同阶段、不同需求的项目中工作。密切关注在这些项目中，哪些部分做起来很“容易”，哪些又异常“艰难”。
2. 聚焦于灵活性：刻意避免形成关于“编写软件的唯一正确方式”的强烈、普适性的观点。始终保持开放，愿意倾听和理解那些与你价值观相悖的观点。
3. 拥抱真实世界的混乱：“好品味”无法在玩具问题或技术问答中得到检验。你必须投身于一个真实的、充满了各种混乱约束的实际问题中，才能锻炼你在多重约束下做出最佳权衡的能力。

小结：从理解“品味”，到成为更好的Gopher

综上所述，Sean Goedecke为我们揭示了一个深刻的层次：“技术品味”是超越“技术能力”的、衡量工程师成熟度的关键标尺。 文章的核心不在于掌握多少工具，而在于面对具体问题时，能否为之匹配一套恰如其分的工程价值观。这正是成熟与僵化、权衡与教条、情境与普适之间的分水岭。一个工程师的成长上限，或许就取决于他/她能否从固守个人偏好，进化到为项目选择最佳价值排序的“好品味”阶段。

这套关于“品味”的哲学，在Go的语境中显得尤为贴切，甚至可以说，它完美地解释了Go语言及其社区文化的形成。

Go语言本身，就是其设计者们“好品味”的结晶。他们没有盲目追随当时其他语言的风潮，而是为“构建大型、可维护的网络服务”这一特定问题，选择了一套恰如其分的工程价值观——将简单性、可读性和性能透明度置于极高的优先级。

这门语言的设计，反过来也在塑造着我们的“品味”。它通过“做减法”，有意地减少了语言的“魔法”，迫使开发者回归到问题的本质，进行更多的第一性原理思考，而不是依赖于复杂的框架或语法糖。在Go社区所推崇的“务实主义”、“显式优于隐式”，以及对“最佳实践”的天然警惕，本质上都是一种对情境化“好品味”的追求。

只有理解了为什么Go是现在这个样子，我们才能在使用这门语言时，做出同样充满“品味”的、与项目需求相匹配的决策，从而真正发挥出Go语言的全部威力，成为一名真正成熟的软件工程师。

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

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

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

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

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

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