23 测试、工具链与部署，都是语言的一部分

测试：内建，零框架

Go 的测试是语言标准库的一部分（testing 包），你不装任何东西就能写测试。约定极简：文件名以 _test.go 结尾，函数名以 Test 开头、接一个 *testing.T：

// 文件 math_test.go
func TestMax(t *testing.T) {
    got := Max(3, 5)
    if got != 5 {
        t.Errorf("Max(3, 5) = %d, 想要 5", got)   // 报错就 t.Errorf
    }
}

然后 go test ./... 跑全部测试。没有 JUnit、没有 @Test 注解、没有 build.gradle 里配测试依赖 —— 测试就是普通的 Go 代码 + 一个约定 + 一条命令。你注意到断言长得很朴素吗（就是 if got != want { t.Errorf(...) }）？这是故意的 —— 下一节说。

表驱动测试：Go 的主流风格

Go 测试有个非常主流、你一定要会的写法 —— 表驱动测试（table-driven test）：把「一组输入 → 期望输出」列成一张表（切片），循环跑：

func TestMax(t *testing.T) {
    cases := []struct {
        name     string
        a, b, want int
    }{
        {"a 大", 5, 3, 5},
        {"b 大", 2, 8, 8},
        {"相等", 4, 4, 4},
        {"负数", -1, -5, -1},
    }
    for _, c := range cases {
        t.Run(c.name, func(t *testing.T) {   // 每行一个子测试
            if got := Max(c.a, c.b); got != c.want {
                t.Errorf("Max(%d,%d)=%d, want %d", c.a, c.b, got, c.want)
            }
        })
    }
}

妙处：加一个测试用例，只需在表里加一行，逻辑完全不用动。t.Run 让每行成为一个独立命名的子测试，哪个挂了一眼看出是哪个用例。这套「用数据描述用例、用循环驱动」的模式，是 Go 测试的招牌，你会在几乎每个 Go 项目里见到它，写起来又快又清楚。

◆ 为什么故意没有断言库

你可能会问：怎么没有 assertEquals、assertThat(x).isEqualTo(y) 这种断言 API？Go 团队故意不提供断言库，理由很「Go」：断言库鼓励你写 assert.Equal(t, want, got)，但一旦失败，报错信息是通用的、你还得回去看是什么值不对；而老实写 if got != want { t.Errorf("...具体上下文...") }，逼你亲手写出一条有意义的失败信息，出问题时信息量更大。

这又是那个一以贯之的取舍：牺牲一点写测试的便利（多打几个字），换测试失败时更清楚的诊断。社区确实有第三方断言库（如 testify），能用，但「原生 if + 有意义的 Errorf」才是 Go 官方推崇的味道。

基准、fuzzing、覆盖率：也都内建

同一套 go test 命令，还顺手给了你几样在别的语言要额外装工具的东西：

// 基准测试：函数名以 Benchmark 开头
func BenchmarkMax(b *testing.B) {
    for i := 0; i < b.N; i++ {   // b.N 由框架自动调到能测准
        Max(3, 5)
    }
}

// 模糊测试（1.18+）：自动生成随机输入找崩溃 / 反例
func FuzzParse(f *testing.F) {
    f.Fuzz(func(t *testing.T, s string) {
        Parse(s)   // 框架会喂各种畸形输入，看你崩不崩
    })
}

命令	给你
`go test -bench=.`	跑基准，报每次操作的纳秒 / 内存分配
`go test -fuzz=Fuzz`	模糊测试，自动找让你崩溃的输入
`go test -cover`	测试覆盖率
`go test -race`	竞态检测（第 21 章，进 CI）
`go tool pprof`	CPU / 内存性能剖析
`go vet`	静态检查，揪出可疑代码

这些全是标准工具链自带的，一行命令，零配置。基准测试、模糊测试、性能剖析、竞态检测 —— 在 JVM 世界，这里每一样几乎都要挑第三方库、配 Gradle 插件。Go 把它们做进了语言本身。这就是第 3 章「工具链即语言」哲学的兑现：写好代码需要的工具，Go 认为是语言的责任，不该外包给生态去各搞一套。

部署：一个静态二进制走天下

现在是最爽的部分。go build 编译出的是一个单独的、静态链接的可执行文件 —— 它把所有依赖（包括 Go 运行时本身）都打包进了这一个文件。这意味着：

目标机器什么都不用装。没有 JVM、没有 Python 解释器、没有 node_modules、没有动态库依赖。把那一个文件拷过去，./myapp 就能跑。
Docker 镜像可以小到几 MB。一个 FROM scratch（空镜像）+ 你那个二进制，就是完整镜像 —— 对比一个带 JRE 的 Java 镜像动辄几百 MB。
没有「在我机器上能跑」的运行时版本地狱。二进制自带一切，行为到哪都一样。

◆ 交叉编译：一条命令，给任意平台出包

更狠的是交叉编译。你在 Mac 上，想给 Linux 服务器、或者树莓派（ARM）出一个可执行文件？改两个环境变量，一条命令：

GOOS=linux GOARCH=amd64 go build —— 在 Mac 上直接编出一个 Linux x86 的二进制。
GOOS=linux GOARCH=arm64 go build —— 编个树莓派能跑的。

不用目标机器、不用交叉编译工具链、不用容器，Go 编译器原生就能给几十种「操作系统 × 架构」组合出包。这个体验和「带着 JVM 和一堆 jar 去部署」「配 NDK 交叉编译」比起来，简直是另一个次元。Go 之所以成为云原生时代（Docker、Kubernetes 都是 Go 写的）的主力语言，这个「一个静态二进制 + 秒级交叉编译」的部署体验，是决定性的原因之一。

Kotlin 对照

⇄ JVM 生态的丰富 vs Go 工具链的自足

测试：JVM 有 JUnit / Kotest / MockK / AssertJ 一整套成熟丰富的测试生态，功能强、社区大，但你要挑、配、学。Go 给你一个够用的内建 testing + 表驱动风格，功能朴素但零配置、全项目一致。这是「丰富但要组装」和「简单但开箱即用」的老对比。你会想念 MockK 那种强大的 mock（Go 的 mock 更手工，靠小接口），但会享受「clone 下来 go test 就能跑，不用先搞定构建」。

部署：这里 Go 是压倒性的。你太熟悉 JVM 的部署了 —— 带 JRE、算 heap、GC 调参、依赖冲突、镜像几百 MB；Android 更是 APK 打包、签名、multidex、ProGuard。Go 的「一个二进制、无运行时、秒级交叉编译、镜像几 MB」是实打实的降维打击。如果你做后端 / CLI / 云原生，仅这一条就足以让 Go 变得极有吸引力。

心态转变：在 JVM 世界，「语言」和「构建 / 测试 / 部署工具」是分开的两摊，你要分别掌握（Kotlin + Gradle + JUnit + Docker…）。在 Go 世界，它们是一体的 —— go 一个命令管编译、测试、基准、格式化、依赖、交叉编译。这种「自足」省掉了你大量花在工具链上的精力，是 Go 工程化最被低估的甜头。

这一章的一句话

Go 把测试、基准、fuzzing、性能剖析、竞态检测全做进了内建工具链（表驱动测试是主流风格、故意没有断言库、一条 go test 全包）；而部署是它的杀手锏——编译成一个无依赖的静态二进制、镜像几 MB、一条命令交叉编译给任意平台，把「发布一个程序」简化到了 JVM 难以想象的程度。这就是「工具链即语言」哲学的终极兑现。

还剩最后一章。我们把这一整本书浓缩成一张从 Kotlin/Java 迁移 Go 的对照表，梳理你最容易犯的错、地道 Go 的心态，然后送你上路 —— 告诉你接下来该读什么、写什么。