单元测试验证逻辑正确性，基准测试衡量性能达标性；二者目标、手段、失败含义均不同，不可混用。TestXxx专注输入输出断言与边界覆盖，BenchmarkXxx仅测效率、需隔离副作用、禁用手动设b.N。
单元测试和基准测试的职责边界在哪
单元测试验证「逻辑是否正确」，基准测试回答「性能是否达标」——二者目标不同、手段不同、失败含义也完全不同。混用会导致测试失焦：比如在 TestFoo 里测耗时，或在 BenchmarkFoo 里断言返回值，都是越界操作。
-
TestXxx函数只关心输入 → 输出是否符合预期，允许t.Error/t.Fatal，必须覆盖边界值（如空输入、溢出、临界点） -
BenchmarkXxx函数只关心执行效率，不检查结果对错；b.N是框架自动调节的迭代次数，不能手动设固定值 - 若函数有副作用（如修改全局状态、写文件），必须在
BenchmarkXxx中清除或隔离，否则基准结果不可复现
什么时候该写 Benchmark 而不是 Test
当你开始怀疑某段代码在真实负载下会拖慢系统，或者想对比两种实现的吞吐差异时，才需要基准测试。单纯“能跑通”不构成写 Benchmark 的理由。
- 典型场景：
json.Marshalvs 自定义序列化、LRU 缓存不同淘汰策略、字符串拼接用strings.Builder还是+ - 反例：测试一个纯计算函数是否返回
42，用Test就够了；加个Benchmark只是凑数 - 注意：
go test -bench=.默认不运行任何TestXxx，需显式加-run=^$避免干扰，否则初始化逻辑可能污染耗时统计
边界模糊地带：如何处理既要看结果又要测性能的函数
比如一个解析器既要返回正确 AST，又要求单次解析 ≤ 10ms。这时不能把断言和计时塞进同一个函数，而应拆成两个独立测试。
- 写
TestParse：专注校验输出结构、错误类型、边界输入（空字节、超长嵌套、非法字符） - 写
BenchmarkParse：只喂入典型合法输入，调用前用b.ResetTimer()排除编译/初始化开销 - 若需关联两者（如“这个输入必须在 5ms 内解析成功”），用 CI 脚本或自定义检查工具，而非塞进测试函数里
容易被忽略的基准测试陷阱
很多人以为 Benchmark 只是多跑几遍，其实 Go 的基准框架对环境敏感度远超预期。
立即学习“go语言免费学习笔记（深入）”；
-
b.N不是并发数，而是单 goroutine 循环次数；想测并发性能，得用b.RunParallel或手动启 goroutine +sync.WaitGroup - 未调用
b.ReportAllocs()时，内存分配信息不会显示；但即使显示了，也要注意：小对象逃逸到堆上未必是 bug，Go 编译器优化可能动态决定 - 基准测试默认不启用 race detector；若被测函数涉及共享变量，需单独运行
go test -race -bench=.，否则竞态问题会被掩盖
最常被轻视的一点：基准测试的输入数据必须稳定。用 rand.Intn 生成随机切片长度，或每次 benchmark 读取不同大小的文件，都会让结果失去可比性——性能测试不是压力测试，它要的是确定性度量。
