Go问答技术文章
-
Go 基准测试开启内存分配报告后，结果变化不一定代表业务代码变慢。本文从计时边界、b.ReportAllocs、B/op、allocs/op 和重复运行入手，区分真实分配与测量噪声。384 收藏 -
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 收藏 -
Go 的 t.Setenv 会修改整个测试进程的环境，并在测试结束后恢复，因此当前测试或并行父测试存在时会被禁止。本文解释测试树中的冲突边界，并比较串行测试、配置注入和独立进程三种处理方式。107 收藏 -
go test 输出 (cached) 时，-count=1 只绕过当前调用的测试结果缓存；go clean -testcache 会让已有测试结果全部失效，但不会清空构建缓存。本文按排查范围说明两者区别，以及如何用 -v 和 GODEBUG 判断是否真正重跑。268 收藏 -
go test 显示 (cached) 不一定是代码没更新。本文用 -count=1、GODEBUG=gocachetest=1 和 go clean -testcache 区分正常复用、输入未纳入缓存键与命令参数问题。456 收藏