Go问答技术文章
-
Go pprof 里的 CPU、mutex 和 block profile 关注的不是同一件事。本文用一个采集窗口说明三者的开关、命令、栈位置和适用边界，帮助你判断到底是 CPU 忙还是 goroutine 在等锁、等通道。250 收藏 -
Go 的 block profile 记录的是同步原语上的阻塞时间，不只包含 Mutex。本文教你从等待栈区分 Mutex、RWMutex、WaitGroup 和 channel，并用 mutex profile 找到真正持锁的代码。378 收藏 -
Go mutex profile 没有热点时，先用 runtime.SetMutexProfileFraction(-1) 读取开关，再确认采样比例、竞争窗口和 pprof 进程；本文还区分 mutex profile 与 block profile 的排查边界。151 收藏 -
Go 基准测试开启内存分配报告后，结果变化不一定代表业务代码变慢。本文从计时边界、b.ReportAllocs、B/op、allocs/op 和重复运行入手，区分真实分配与测量噪声。384 收藏 -
Golang · Go问答 | 6天前 | 性能优化 · Go问答 · benchmark · Go测试 · 性能测试 Go 内存分配 testing.AllocsPerRun BenchmarkAllocsPerRun
Go 的 testing.AllocsPerRun 数值变化大时，先排查初始化、输入状态复用、并行测试和后台分配，再决定增加 runs 还是改用 benchmark。本文按测量边界、稳定输入和指标分工给出一套可执行的检查顺序。223 收藏 -
Go benchmark 结果忽高忽低，常见原因不是被测函数本身，而是初始化落在计时区间、分配统计未分开或运行噪声未被重复确认。本文用 testing.B 说明 StopTimer、ResetTimer、ReportAllocs 和 -count 的配合方式。368 收藏 -
Go covermode 的选择取决于是否并发以及是否需要可靠执行次数：串行包/函数覆盖率用 set，并发计数或 -race 场景用 atomic。139 收藏 -
Go 覆盖率统计到函数并不代表每个分支都执行。本文用表驱动测试区分包覆盖率、函数覆盖率和代码块报告，定位没有命中的分支。195 收藏 -
go test -coverprofile 默认只分析正在测试的包。要把模块内子包纳入同一份报告，需要同时指定测试包列表和 -coverpkg=./...，再用 go tool cover 查看函数或 HTML 报告。178 收藏 -
Go fuzz 最小化输入仍无法复现时，先核对失败日志中的 FuzzXxx/哈希、testdata corpus 路径和参数类型，再排查时间、随机数、全局状态与外部依赖，最后把稳定 corpus 固化为回归测试。236 收藏 -
Go fuzz 运行很慢时，先用 -run 和 -fuzz 只选一个目标，再用 -fuzztime 限制探索预算；语料保留能覆盖不同入口的种子，失败输入最小化另用 -fuzzminimizetime 控制，并按机器压力调整 -parallel。256 收藏 -
Go fuzz 测试发现失败输入后，会把最小化样例写入 testdata/fuzz/FuzzXxx。保留这个 corpus 文件，再用 go test -run 复现并纳入版本库，就能把随机发现的问题变成稳定回归用例。455 收藏 -
Go 多包测试中，TestMain 不是全局入口：每个包拥有独立测试二进制。本文说明 m.Run 返回码、清理逻辑和 os.Exit 的边界，避免初始化重复、defer 不执行和失败状态丢失。125 收藏 -
Go TestMain 初始化失败不能只写 return，否则测试入口可能按 m 的默认退出状态结束。本文说明 m.Run、资源清理、flag.Parse 与 os.Exit 的正确组合。227 收藏 -
Go TestMain 中直接调用 os.Exit 会跳过 defer 清理。本文拆解 m.Run、TestMain 返回和测试包装器的关系，给出失败时仍释放资源、同时保留正确退出码的写法。184 收藏