测试
需要预先了解：
1. 测试
Go 把测试做成了语言工具链的一部分：_test.go 文件、go test 命令、testing 包，不需要额外框架。这一篇讲单元测试、表驱动测试、基准测试、模糊测试、示例测试和 HTTP 测试的写法，以及覆盖率怎么读。
1.1 测试文件的组织
测试代码放在以 _test.go 结尾的文件里，和被测试代码同一个目录：
calc/
├── calc.go // package calc
├── calc_test.go // package calc（同包测试）
└── calc_ext_test.go // package calc_test（外部测试包）两种包名的区别：
| 写法 | 能访问 | 适合 |
|---|---|---|
package calc |
包内所有标识符（含未导出的） | 测试内部实现 |
package calc_test |
只有导出的标识符 | 测试对外 API，避免依赖内部细节 |
同一个目录下两种测试文件可以共存。外部测试包需要 import 被测包：
package calc_test
import (
"testing"
"note26/calc"
)
func TestExternalPackage(t *testing.T) {
if calc.Add(1, 2) != 3 {
t.Error("Add 结果不对")
}
}1.2 单元测试
测试函数必须以 Test 开头，签名是 func TestXxx(t *testing.T)：
func TestAdd(t *testing.T) {
if got := Add(1, 2); got != 3 {
t.Errorf("Add(1, 2) = %d, 期望 3", got)
}
}失败相关的几个方法：
| 方法 | 行为 |
|---|---|
t.Error |
标记失败，继续执行当前测试 |
t.Errorf |
带格式化，标记失败，继续执行 |
t.Fatal |
标记失败并立即终止当前测试函数 |
t.Fatalf |
带格式化，立即终止 |
t.FailNow |
只终止，不额外记录信息 |
一般原则：断言失败用 Error，继续跑完所有检查（能看到更多问题）；前置条件不成立用 Fatal（继续跑下去会 panic 或产生无意义的报错）。
t.Log 记录的信息默认不显示，加 -v 或测试失败时才输出：
=== RUN TestWithLog
calc_test.go:84: 这条日志只在 -v 或失败时显示
calc_test.go:85: 带格式化: 42
--- PASS: TestWithLog (0.00s)1.3 表驱动测试
同一段逻辑测多组输入时，把用例写成表：
func TestTableDriven(t *testing.T) {
tests := []struct {
name string
a, b int
want int
wantErr bool
}{
{"正整数", 10, 2, 5, false},
{"整除余数", 7, 2, 3, false},
{"负数", -9, 3, -3, false},
{"除数为零", 1, 0, 0, true},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
got, err := Div(tt.a, tt.b)
if tt.wantErr {
if err == nil {
t.Fatalf("期望出错，但没有")
}
return
}
if err != nil {
t.Fatalf("意外错误: %v", err)
}
if got != tt.want {
t.Errorf("Div(%d, %d) = %d, 期望 %d", tt.a, tt.b, got, tt.want)
}
})
}
}t.Run 创建子测试，好处是：
- 输出里能看到具体哪个用例失败；
- 可以单独运行某个用例：
go test -run 'TestTableDriven/除数为零'； - 可以在子测试里调用
t.Parallel()。
=== RUN TestTableDriven/正整数
=== RUN TestTableDriven/整除余数
=== RUN TestTableDriven/负数
=== RUN TestTableDriven/除数为零
--- PASS: TestTableDriven (0.00s)
--- PASS: TestTableDriven/正整数 (0.00s)
...并行子测试
for _, tt := range tests {
tt := tt
t.Run("", func(t *testing.T) {
t.Parallel()
// ...
})
}t.Parallel() 会暂停当前子测试，让其他并行子测试先跑。注意循环变量的捕获：Go 1.22 之前需要 tt := tt，1.22+ 每轮迭代已经是新变量（见 并发设计模式与陷阱总结）。
1.4 基准测试
基准函数以 Benchmark 开头，签名是 func BenchmarkXxx(b *testing.B)：
func BenchmarkAdd(b *testing.B) {
for i := 0; i < b.N; i++ {
_ = Add(i, i+1)
}
}b.N 由测试框架自适应确定：先小规模试跑，再逐步增大，直到测量时间足够长（默认约 1 秒），最后报告"每次操作耗时"。
计时控制：
b.ResetTimer() // 重置计时，忽略之前的准备工作
b.StopTimer() // 暂停计时（做准备工作）
b.StartTimer() // 恢复计时
b.ReportAllocs() // 报告内存分配（等价于命令行加 -benchmem）实测输出：
BenchmarkAdd-24 1000000000 0.1099 ns/op 0 B/op 0 allocs/op
BenchmarkFormat-24 90657721 12.95 ns/op 7 B/op 0 allocs/op
BenchmarkConcatPlus-24 1234840 1173 ns/op 1504 B/op 49 allocs/op
BenchmarkConcatBuilder-24 5698204 193.5 ns/op 120 B/op 4 allocs/op列的含义：
| 列 | 含义 |
|---|---|
BenchmarkX-24 |
函数名；-24 是 GOMAXPROCS |
ns/op |
每次操作耗时（纳秒） |
B/op |
每次操作分配的内存字节数 |
allocs/op |
每次操作分配次数 |
看性能问题先看 allocs/op：分配次数多通常意味着 GC 压力大。上面 + 拼接字符串每次 49 次分配、1504 字节，Builder 只有 4 次分配、120 字节——和 切片、map 与字符串的底层实现 里的结论一致。
运行方式：
go test -bench . -benchmem -run "^$"-run "^$" 表示不跑普通测试，只跑基准。
1.5 模糊测试（Go 1.18+）
**模糊测试（fuzzing）**自动生成输入，寻找让程序崩溃或违反断言的用例：
func FuzzAdd(f *testing.F) {
f.Add(1, 2) // 种子语料
f.Add(-1, 1)
f.Add(0, 0)
f.Fuzz(func(t *testing.T, a, b int) {
got := Add(a, b)
if got != b+a {
t.Errorf("Add(%d, %d) 交换顺序后不一致", a, b)
}
})
}f.Add提供种子语料，go test默认会跑这些种子；go test -fuzz=FuzzAdd -fuzztime=3s才会真正开始生成随机输入：
fuzz: elapsed: 0s, gathering baseline coverage: 3/3 completed, now fuzzing with 24 workers
fuzz: elapsed: 3s, execs: 2309425 (769667/sec), new interesting: 0 (total: 3)
PASS- 一旦发现失败用例，它会被写入
testdata/fuzz/FuzzXxx/目录，之后每次go test都会复现它； - 参数类型支持
string、[]byte、int、float64、bool等基本类型。
模糊测试特别适合解析器、编解码器这类"输入空间巨大"的代码。
1.6 示例测试
ExampleXxx 函数既当文档又当测试，用 // Output: 注释声明期望输出：
func ExampleAdd() {
fmt.Println(Add(1, 2))
// Output: 3
}
func ExampleFormat() {
fmt.Println(Format(42))
fmt.Println(Format(-1))
// Output:
// 42
// -1
}go test 会执行它并比对输出，不一致就失败。它们会出现在 go doc 里，作为可执行的文档。
1.7 httptest
测试 HTTP 处理器有两种方式。
httptest.NewRecorder：不启动真实服务器，直接调用 ServeHTTP 并检查响应：
body := strings.NewReader(`{"name":"一撮灰"}`)
req := httptest.NewRequest(http.MethodPost, "/users", body)
rec := httptest.NewRecorder()
h.ServeHTTP(rec, req)
if rec.Code != http.StatusCreated {
t.Fatalf("创建状态码 = %d, 期望 201", rec.Code)
}httptest.NewServer：启动一个真实的测试服务器，适合测试客户端逻辑或端到端流程：
srv := httptest.NewServer(h)
defer srv.Close()
resp, err := http.Post(srv.URL+"/users", "application/json", strings.NewReader(`{"name":"灰灰"}`))httptest.NewServer 用的是真实网络端口，测试结束后要 Close。它也是 标准库（二）：JSON 与 HTTP 服务 里那个服务的标准测试方式。
1.8 覆盖率
go test -cover ./...ok note26/api 0.479s coverage: 96.2% of statements
ok note26/calc 0.430s coverage: 100.0% of statements生成详细报告：
go test -coverprofile=cover.out ./calc
go tool cover -func=cover.out
go tool cover -html=cover.out # 生成可视化 HTMLnote26/calc/calc.go:11: Add 100.0%
note26/calc/calc.go:16: Div 100.0%
note26/calc/calc.go:24: Format 100.0%
note26/calc/calc.go:29: unexported 100.0%
total: (statements) 100.0%注意：覆盖率衡量的是"哪些代码被执行过"，不是"哪些情况被验证过"。100% 覆盖的代码里照样可能藏着 bug。覆盖率适合用来发现完全没被测试碰到的代码，不适合当作质量指标。
1.9 testify 概览
标准库的断言写起来比较啰嗦，第三方库 github.com/stretchr/testify 提供了更简洁的写法：
| 包 | 作用 |
|---|---|
assert |
断言失败记录错误并继续 |
require |
断言失败立即终止当前测试 |
mock |
生成 mock 对象 |
suite |
测试套件，共享 setup/teardown |
assert.Equal(t, 3, Add(1, 2))
require.NoError(t, err)它不是必需的——标准库足够写完所有测试。团队引入前先确认收益是否大于多一个依赖。
1.10 go test 常用参数
| 参数 | 作用 |
|---|---|
-v |
显示详细输出 |
-run |
按正则筛选测试：-run 'TestDiv/除数为零' |
-bench |
运行基准测试 |
-benchmem |
显示内存分配统计 |
-count |
重复运行次数：-count=1 禁用缓存 |
-race |
开启数据竞争检测 |
-timeout |
超时时间，默认 10 分钟 |
-short |
启用"短模式"，测试内用 testing.Short() 判断 |
-cover |
输出覆盖率 |
-fuzz |
运行模糊测试 |
go test 默认会缓存成功的测试结果，改了代码或加 -count=1 才会重跑。
1.11 练习
- 给 泛型 里的
Set[T]写表驱动测试，覆盖 Add、Has、Remove、重复添加等场景。 - 给 标准库（一）：IO 与系统交互 里的文件读写函数写测试，用
t.TempDir()创建临时目录，避免污染工作目录。 - 写一个基准测试对比
map与slices线性查找在 10、100、1000 个元素时的性能差异，根据ns/op给出"多大时该用 map"的建议。
相关推荐
2026-09-09
标准库（一）：IO 与系统交互
需要预先了解： 接口 包与模块：代码组织 错误处理 标准库（一）：IO 与系统交互 io.Reader 和 io.Writer 是 Go 标准库最重要的两个接口，几乎所有"数据从哪里来、到哪里去"的 API 都建立在这两个接口上。这一篇讲清楚它们的语义、如何用它们拼装数据流，以及 fmt、os、bufio、time、flag 的常用部分。 io.Reader 与 io.Writer 两个接口的签名极简： type Reader interface { Read(p []byte) (n int, err error) } type Writer interface { Write(p []byte) (n int, err error) } Read 的语义：最多读 len(p) 个字节到 p 里，返回实际读到的字节数 n。 n > 0：读到了数据，err 可能是 nil，也可能是 io.EOF（最后一个数据块同时到达末尾）； n == 0, err == io.EOF：正常...
2026-09-09
标准库（二）：JSON 与 HTTP 服务
需要预先了解： 结构体与指针 标准库（一）：IO 与系统交互 context 标准库（二）：JSON 与 HTTP 服务 encoding/json 和 net/http 是写服务端程序的两块基石。这一篇从"结构体怎么变成 JSON"讲到"一个带中间件、超时和优雅关闭的迷你 REST 服务"，把 反射与 unsafe 里看到的 tag 机制落到实际用法上。 encoding/json 基础 两个函数覆盖 90% 的场景： b, err := json.Marshal(v) // 值 -> JSON 字节切片 err = json.Unmarshal(data, &v) // JSON -> 值（必须传指针） u := User{Name: "一撮灰", Score: 98.5, Created: time.Date(2026, 9, 9, 12, 0, 0, 0, time.UTC)} b, _ := json.Marshal(u) fmt.Println...
2026-09-09
性能分析与调优
需要预先了解： 内存分配与逃逸分析 垃圾回收 测试 性能分析与调优 性能优化的第一条原则是先测量，再优化。凭直觉猜"哪里慢"十有八九猜错，而且容易把代码改得更复杂却没有任何收益。Go 工具链把测量能力做得很完整：testing 做基准、pprof 找热点、trace 看调度。 方法论 建立基线：用 testing.B 写基准测试，记录当前的 ns/op、B/op、allocs/op； 找到瓶颈：用 pprof 看 CPU/内存/阻塞的分布，而不是猜； 只改一个变量：一次改一处，改完重新测量； 验证收益：与基线对比，没有明显提升就回退； 防止退化：把关键基准保留在仓库里，配合 CI 定期跑。 优化的收益通常遵循帕累托分布：少数几处热点贡献了大部分开销。先解决它们，再考虑细节。 采集 profile 文件式采集（runtime/pprof） 在程序里显式启动： f, _ := os.Create("cpu.prof") pprof.StartCPUProfile(f) defer pprof.StopCPUProfile() ...
2026-09-09
接口与 channel 的底层实现
需要预先了解： 接口 channel 内存分配与逃逸分析 接口与 channel 的底层实现 接口 里留下的 nil 陷阱、channel 里"收发是拷贝"的结论，都可以从运行时结构上得到解释。这一篇看 eface/iface/itab 和 hchan 的真实字段，以及一次发送、一次接收、一次关闭在底层分别发生了什么。 eface 与 iface 空接口和非空接口在运行时是两种结构： type eface struct { // 空接口 any / interface{} _type *_type // 动态类型 data unsafe.Pointer // 指向动态值的指针 } type iface struct { // 带方法的接口 tab *itab // 类型 + 方法表 data unsafe.Pointer // 指向动态值的指针 } 两者都是两个指针宽，在 64 位平台上是 16...
2026-09-09
channel
需要预先了解： goroutine 与并发初探 channel channel 是 goroutine 之间传递数据的管道，也是 Go 并发模型的核心。它同时承担两件事：传递数据和同步。这一篇讲清楚无缓冲与有缓冲的差别、close 的规则、select 的多路复用，以及几个会让程序直接崩溃的操作。 设计哲学 Go 的并发信条是： 不要通过共享内存来通信，而要通过通信来共享内存。 意思是：与其让多个 goroutine 抢着读写同一块内存（然后用锁保护），不如让数据在 goroutine 之间传过来，同一时刻只有一方持有它。channel 就是传递的载体。 无缓冲 channel：同步语义 make(chan T) 创建的是无缓冲 channel。它的发送和接收必须同时就位才能完成——发送方会一直阻塞，直到有接收方来取： ch := make(chan int) go func() { fmt.Println("发送前") ch <- 1 fmt.Println("发送完成") }() time.Sleep(100 * ti...
2026-09-09
内存分配与逃逸分析
需要预先了解： 数组与切片 结构体与指针 方法 内存分配与逃逸分析 一个变量分配在栈上还是堆上，由编译器通过**逃逸分析（escape analysis）**决定。这个决定直接影响性能：栈分配只是移动一下栈指针，几乎零成本；堆分配要走分配器、还要被垃圾回收扫描。这一篇讲清楚逃逸分析怎么看、哪些写法会让变量逃逸，以及内存对齐和分配大小分级这两个容易忽略的细节。 栈与堆 维度 栈 堆 分配成本 极低（移动栈指针） 较高（分配器 + 可能的锁） 回收方式 函数返回时自动释放 由垃圾回收器回收 生命周期 与函数调用绑定 由可达性决定 访问速度 更快（缓存友好） 稍慢 Go 的 goroutine 栈是动态增长的：初始约 8KB，不够时自动扩容（最大到 1GB，64 位平台）。栈上变量的地址在扩容时会被修正，所以程序里取到的指针在逻辑上始终有效。 Go 的分配器 Go 运行时自带内存分配器，按对象大小走不同的路径： 小对象（≤ 32KB）： mcache（每个 P 私有，无锁） | mcent...
