Go 怎么写基准测试比较两种 JSON 编码方案

比较两种 Go JSON 编码方案时，关键不是把两个函数各跑一遍，而是让它们在同一份输入、同一计时范围和同一结果约束下反复执行。最实用的起点是用 testing.B 建两个子基准：一个测 json.Marshal，另一个测复用 bytes.Buffer 的 json.Encoder，再调用 b.ReportAllocs() 观察分配次数。

下面的示例没有给出“谁永远更快”的结论。基准结果会受 Go 版本、CPU、输入规模和复用策略影响；它要回答的是：在你声明的这组条件下，哪种方案的时间、内存和输出语义更适合当前代码。

先固定 JSON 输入与比较口径

测试数据应在基准函数外准备好，循环里只做编码。这样可以避免每次迭代重新拼装切片或填充结构体，把数据准备成本误算成编码成本。两种方案必须编码完全相同的值；如果业务需要精确的响应体，还要注意 Encoder.Encode 会在 JSON 后写入换行，而 Marshal 返回的字节切片不带这个换行。

用 Benchmark 子基准分别测两种方案

把测试放在名为 json_benchmark_test.go 的文件中。b.Run 能把两种实现放到同一个基准下，最终报告会分别显示每次操作的耗时和分配。ReportAllocs 只影响调用它的这个基准函数，不会改变生产代码。

package jsonbench

import (
    "bytes"
    "encoding/json"
    "testing"
)

type Event struct {
    ID      int      `json:"id"`
    Kind    string   `json:"kind"`
    Labels  []string `json:"labels"`
    Enabled bool     `json:"enabled"`
}

var benchmarkSink []byte

func BenchmarkJSONEncode(b *testing.B) {
    payload := Event{
        ID: 42, Kind: "build.finished",
        Labels: []string{"go", "benchmark", "json"}, Enabled: true,
    }

    b.Run("Marshal", func(b *testing.B) {
        b.ReportAllocs()
        b.ResetTimer()
        for i := 0; i 

这里的 benchmarkSink 用来保留最后一次结果引用，避免编译器认为输出完全没有用途。它不是并发安全的共享业务变量，只用于这个顺序执行的基准示例。若测试包本身会并行运行多个基准，应改用各自的局部 sink 或在设计上隔离状态。

复用缓冲区，但不要把准备工作混进循环

Encoder 和 bytes.Buffer 都在计时开始前创建，循环里只重置缓冲区并编码。这样测到的是“已有写入器如何处理这份值”，通常适合比较长连接响应、批量写文件等确实会复用对象的场景。

这也意味着它与 json.NewEncoder(&bytes.Buffer{}) 每次重新创建的方案不是同一个问题。如果生产代码每个请求都会新建 Encoder，应该再增加一个名为 EncoderPerOperation 的子基准，把真实创建和释放成本写进循环，而不是拿复用结果代替它。

另一个常见误区是为了让两种方案“看起来一样”，把 Encoder 的换行裁掉后再比较。裁剪会增加额外工作，也会改变被测方案。更好的做法是先声明响应协议是否允许末尾换行：允许就保留；不允许就让两边都输出相同的最终格式，并把这段格式化成本明确纳入基准。

运行基准并解读差异

在模块根目录运行下面的命令，先固定一次运行中的迭代时间，再重复多次观察趋势：

# -bench 只运行名称匹配的基准；-benchmem 输出每次操作的分配指标。
go test -run '^$' -bench '^BenchmarkJSONEncode$' -benchmem -count=5

重点看三列：

• ns/op：每次编码耗时，越低表示在当前机器和输入下越快。
• B/op：每次操作分配的字节数，反映分配压力，不等于总常驻内存。
• allocs/op：每次操作的分配次数，适合发现对象创建和扩容带来的压力。

不要只看一次输出就下结论。先确认两组基准的输入、输出要求和复用策略相同，再看五次结果是否方向稳定。如果 EncoderReuseBuffer 少分配但耗时没有优势，这并不矛盾：分配次数只是一个指标，编码逻辑、写入器边界和 CPU 缓存也会影响时间。

按真实业务边界补一组端到端基准

函数级基准适合回答编码器本身的差异，但线上请求还可能包含对象构造、压缩、网络写入、日志和错误处理。完成基础对比后，可以再写一组端到端基准，例如把 JSON 写到一个实现了 io.Writer 的测试对象中，并决定是否包含响应头、压缩或对象池。

建议在代码评审里记录四件事：输入大小和字段分布、是否复用 Buffer、是否包含对象创建、输出是否允许换行。这样后续换 Go 版本或换机器重跑时，结果仍然有可比的上下文。

常见问题

为什么基准里要调用 b.ReportAllocs？

它会让基准报告分配字节数和分配次数，帮助你判断“更快”是否伴随更高的分配压力；它不会自动告诉你哪种方案适合业务。

json.Marshal 和 Encoder.Encode 的输出完全一样吗？

不一定。Encode 会追加换行，Marshal 不会。需要字节级一致时，应把最终输出协议写进测试断言和基准口径。

为什么不能把 payload 的构造放在 benchmark 循环里？

因为那会把测试数据准备、切片创建等成本混进编码耗时。若你确实想测完整请求，就保留它，但应把基准名称和结论改成端到端场景。

一句话总结：先用同一份输入建立可解释的 testing.B 对比，再用 ReportAllocs 观察内存指标，最后把复用和输出格式的真实约束补进端到端基准。