本文永久链接 – 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技能再上一个新台阶！

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

本文永久链接 – https://tonybai.com/2025/09/29/synctest-bugs-in-go-1-25

大家好，我是Tony Bai。

Go 1.25的发布，为我们带来了一个期待已久的“并发测试神器”—— testing/synctest。这个在Go 1.24中作为实验性功能首次亮相的包，承诺将我们从time.Sleep、channel和各种脆弱的同步技巧中解放出来，让我们能够编写出快速、可靠、确定性的并发测试。

然而，任何强大的新工具在投入真实世界的熔炉后，都必然会经历一场严酷的“成人礼”。Go 1.25发布后，社区的早期使用者们迅速将其应用于各种复杂的并发场景，并遇到了一些隐藏在“气泡”（bubble）之下的微妙问题。

本文将聚焦于三个典型的、由社区报告的synctest“首日bug” (#75052, #74837, #75134)，它们分别涉及了io.Pipe、context和sync.WaitGroup这三个常用并发原语。需要澄清的是，这些所谓“Bug”并非都是synctest本身的Bug。它们有的源于开发者对并发原语的常见误用，synctest只是更严格地揭示了问题；有的则反映了一个实验性API在社区反馈下的设计演进；当然，其中也包含了一个深藏在运行时中的、真正的实现Bug。

通过剖析这些案例，我们不仅能学会如何正确、安全地使用synctest，更能一窥这个新范式背后的设计哲学、Go团队的应对智慧以及它如何帮助我们编写更健壮的并发代码。

Bug 1: io.Pipe与context的“谎言”—— Goroutine泄漏之谜

一位开发者在迁移测试到synctest后，遇到了一个神秘的panic：panic: deadlock: main bubble goroutine has exited but blocked goroutines remain。这通常意味着测试中存在goroutine泄漏。

你可以将以下代码保存为leak_test.go并运行go test来复现这个panic。

// synctest-bugs/bug1/leak_test.go
package main_test

import (
    "context"
    "io"
    "testing"
    "testing/synctest"
)

func TestGoroutineLeakWithPipe(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        pr, pw := io.Pipe()

        // 这个后台goroutine在pr上阻塞读取，等待数据或EOF
        go func() {
            io.ReadAll(pr)
        }()

        ctx, cancel := context.WithCancel(context.Background())
        defer cancel()

        // 主测试goroutine错误地认为cancel()可以结束测试
        // 但实际上，后台goroutine仍在pr上阻塞
        _ = pw
        _ = ctx
    })
    // 当synctest.Test返回时，它检测到后台goroutine没有退出，
    // 于是触发panic，报告goroutine泄漏。
}

在Go 1.25.0下运行上述测试，我们会得到类似下面的panic：

$go test
--- FAIL: TestGoroutineLeakWithPipe (0.00s)
panic: deadlock: main bubble goroutine has exited but blocked goroutines remain [recovered, repanicked]
... ...

经过Go团队分析，该问题根源被定位为：被遗忘的Reader：

• io.Pipe的行为: io.PipeReader上的Read会一直阻塞，直到PipeWriter写入了数据，或者PipeWriter被关闭（发送EOF信号）。
• context的局限: context.Cancel()的信号无法神奇地中断底层的I/O操作，因为它没有与io.Pipe进行任何形式的集成。

在问题代码中，cancel()被调用，但pw（PipeWriter）从未被关闭。因此，后台的reader goroutine被永远地阻塞了，导致了synctest检测到的泄漏。

解决方案很简单：在测试结束前，必须显式地关闭PipeWriter。

func TestGoroutineLeakFixed(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        pr, pw := io.Pipe()
        defer pw.Close() // <--- 关键修复！

        go func() {
            io.ReadAll(pr)
        }()
        // ...
    })
}

pw.Close()会向pr发送一个EOF错误，安全地解除后台goroutine的阻塞。

为了避免后续发生类似使用问题，Go团队还是在synctest包增加了使用注释，以提醒使用者避免上述问题：

不过，synctest的严格性是一件好事。它像一个哨兵，将那些在传统测试中可能被掩盖的、潜在的goroutine泄漏问题，以一个明确的panic暴露出来。synctest不仅测试逻辑，还在检验你并发代码的“卫生状况”。

Bug 2: context与“气泡”边界的微妙冲突

另一个issue揭示了synctest与context包之间一个更深层次的交互问题，导致测试在“气泡”退出后神秘地挂起。

这个问题主要存在于Go 1.24的实验性API synctest.Run中，你可以通过下面的代码在GOEXPERIMENT=synctest下复现该问题：

// synctest-bugs/bug2/oldapi_test.go
package main_test

import (
    "context"
    "testing"
    "testing/synctest" // 假设这是Go 1.24的旧版本
)

// 这个测试在Go 1.24 + synctest.Run下会挂起
func TestContextBoundaryIssue(t *testing.T) {
    synctest.Run(func() { // 旧API
        _, cancel := context.WithCancel(t.Context())
        defer cancel()
    })
    // t.Cleanup() 中对 t.Context() 的 cancel 操作
    // 会在 "气泡" 外关闭一个 "气泡" 内的channel，引发panic和死锁。
}

这个问题的根源是跨“气泡”边界的非法操作：

1. 在synctest.Run的函数体内，t.Context()返回的context属于“气泡”内部。
2. context.WithCancel为这个“气泡内”的context创建了一个done channel，这个channel也属于“气泡”。
3. 当测试函数返回，testing框架的t.Cleanup在“气泡”之外尝试关闭这个done channel。
4. 这个跨边界的非法操作触发了synctest的panic。不幸的是，这个panic发生在context包内部的互斥锁还未释放时，后续的清理操作导致了死锁。

Go 1.25正式版的API synctest.Test(t testing.T, func(t *testing.T) { … })完美地解决了这个问题。它会为“气泡”内部的执行创建一个作用域限定在“气泡”内的新testing.T，其生命周期与“气泡”完全绑定，从而避免了边界冲突。下面是使用新API后的运行正常的代码：

// synctest-bugs/bug2/newapi_test.go
package main

import (
        "context"
        "testing"
        "testing/synctest" // 这是Go 1.25的新版本
)

func Test(t *testing.T) {
        synctest.Test(t, func(t *testing.T) {
                _, cancel := context.WithCancel(t.Context())
                defer cancel()
        })
}

新版API下，synctest的“气泡”是一个严格的隔离边界，它不仅隔离时间和goroutine，还隔离了同步原语的“所有权”。编写synctest测试时，要时刻保持对“气泡”边界的敬畏。

Bug 3: sync.WaitGroup的并发“幽灵”

sync.WaitGroup是Go中最基础的并发原语之一，但在synctest中高并发地使用它时，却出现了莫名超时或panic的现象。

issue提出者给出一个在Go 1.25.0下复现该bug的代码:

// synctest-bugs/bug3/wg_race_test.go
package main_test

import (
    "context"
    "sync"
    "testing"
    "testing/synctest"
)

func TestSyncTest_Wait_Group(t *testing.T) {
    for range 1000 {
        doSyncTestWithChanel(t)
    }
}

func doSyncTestWithChanel(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        ctx, cancel := context.WithCancel(context.Background())

        for range 100 {
            go func() {
                simpleWait(ctx)
            }()
        }

        synctest.Wait()
        cancel()
    })
}

func simpleWait(ctx context.Context) {
    var wg sync.WaitGroup
    for range 3 {
        wg.Go(func() {
            <-ctx.Done()
        })
    }
    wg.Wait()
}

使用Go 1.25.0运行该测试代码，会得到下面panic：

$ go test -bench .
fatal error: sync: WaitGroup.Add called from multiple synctest bubbles
... ...

问题的根源在于一个隐藏在Go运行时内部的细节。在synctest模式下，Go运行时需要追踪每一个sync.WaitGroup实例究竟属于哪个“气泡”。这是通过在WaitGroup首次被使用时，为其分配一个特殊的内部记录来实现的。

然而，在Go 1.25的早期版本中，这个分配操作没有被正确地加锁。当多个goroutine在高并发下同时初始化新的WaitGroup实例时，它们会并发地读写这个用于分配记录的全局数据结构，从而导致内存损坏或逻辑错乱。

解决方案非常直接：为这个内部记录的分配过程加上了正确的锁（mheap_.speciallock）。这个修复被迅速合并，并被紧急向后移植（backport）到了Go 1.25的发布分支中。

由此bug也可以看到，testing/synctest的实现远不止是一个简单的库，它与Go的运行时和调度器进行了深度集成。这种集成赋予了它控制时间的强大能力，但也意味着它可能会暴露或引入极深层次的运行时bug。Go团队对这类问题的快速响应和紧急修复，也体现了他们对这个新API稳定性的高度重视。

小结：一个正在走向成熟的“并发测试新范式”

这三个“首日bug”的故事，非但没有削弱testing/synctest的价值，反而让我们更加清晰地看到了它的设计哲学和强大之处：

• 它是严格的“教官”: 它会无情地暴露你代码中隐藏的goroutine泄漏和同步问题。
• 它是精密的“仪器”: 它的“气泡”边界需要被精确理解和尊重。
• 它是运行时的“延伸”: 它的稳定性依赖于与Go运行时的深度协同。

通过社区的积极反馈和Go团队的快速迭代，testing/synctest已经成功地度过了它的“成人礼”。它可能不会让并发测试变得“简单”，因为并发本身从不简单。但正如官方博客所说，它能让你编写出最简单的并发代码，使用最地道的Go和标准库，然后为它们编写出快速、可靠的测试。 这，或许就是它能带给我们的最大价值。

本文涉及的示例源码可以在这里下载。

如果你觉得今天的案例分析意犹未尽，渴望系统性地学习synctest的每一个细节，那么我诚挚地邀请你订阅我的微专栏——《征服Go并发测试》。在这三讲内容中，我们将深入剖析 Go 1.25 并发测试“新武器”——testing/synctest，从痛点到官方设计，再到实战案例，手把手教你用“气泡”与“合成时间”驯服并发猛兽，写出闪电般快速、坚如磐石的并发测试！点击此处或扫描下方二维码立即解锁，让你的 Go 并发技能跃迁！

参考资料

• https://github.com/golang/go/issues/75052
• https://github.com/golang/go/issues/74837
• https://github.com/golang/go/issues/75134

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

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

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

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

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

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