Go encoding/json.Encoder 怎样减少临时分配

减少 encoding/json.Encoder 周边的临时分配，先删掉应用层不必要的 Marshal、string 与 []byte 往返转换：可以直接把 Encoder 绑定最终 io.Writer。必须暂存时，在同一个串行处理范围内复用 bytes.Buffer，并用 Reset 重用容量。Encoder 不承诺零分配，缓冲区复用也不保证降低整个进程的峰值内存。

官方地址：https://pkg.go.dev/encoding/json

先保护内存预算和数据所有权

本题关注两个资源：每条记录产生的中间对象，以及复用对象长期持有的容量。前者影响分配压力，后者可能让一个偶发大对象把常驻内存拉高。优化目标应是减少多余复制，同时保持错误处理、输出格式和对象所有权清晰。

典型多余路径是先 Marshal 得到字节，再转成字符串，最后又交给需要字节的写入接口。是否真的发生堆分配取决于具体代码和编译优化，但这些转换在设计上通常可以直接去掉。本文提供原创实现，没有执行代码或编造 allocs/op 数据。

优先让 Encoder 持有最终 Writer

下面的 writeRecords 把编码结果写向调用者提供的目标。另一个 writeStaged 仅供需要“先完成本条编码再交给下游”的场景使用，二者择一，不要在同一输出里串行调用而重复写入。

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "os"
)

type Record struct {
    ID int `json:"id"`
    Label string `json:"label"`
}

// writeRecords 直接写最终目标，省掉应用层 Marshal 后再转字符串的中间路径。
func writeRecords(w io.Writer, rows []Record) error {
    enc := json.NewEncoder(w)
    for _, row := range rows {
        if err := enc.Encode(row); err != nil {
            return fmt.Errorf("编码记录 %d: %w", row.ID, err)
        }
    }
    return nil
}

// writeStaged 每条先编码到可复用缓冲区，再同步写出；仅限单个调用内使用。
func writeStaged(w io.Writer, rows []Record) error {
    var buf bytes.Buffer
    enc := json.NewEncoder(&buf)
    for _, row := range rows {
        buf.Reset() // 清空长度但保留底层容量，供下一条复用。
        if err := enc.Encode(row); err != nil {
            return fmt.Errorf("暂存编码 %d: %w", row.ID, err)
        }
        data := buf.Bytes() // 借用视图，只在本轮同步 Write 期间使用。
        n, err := w.Write(data)
        if err != nil {
            return fmt.Errorf("写出记录 %d: %w", row.ID, err)
        }
        if n != len(data) {
            return io.ErrShortWrite // 不把不完整写入当作成功。
        }
    }
    return nil
}

func main() {
    // 示例面向逐条 JSON，不构造 JSON 数组；stdout 由进程持有，无需在此关闭。
    rows := []Record{{ID: 1, Label: "alpha"}, {ID: 2, Label: "beta"}}
    if err := writeRecords(os.Stdout, rows); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

Encode 会在 JSON 值后附加换行，因此这段程序表达的是一条一条的 JSON 值，不能冒充一个 JSON 数组。输出协议若要求精确字节或签名，改写前必须把换行差异纳入协议设计。writer 的创建、关闭或刷新由持有它的上层负责；如果传入 bufio.Writer，上层还要处理 Flush 的错误。

确有暂存需求时，再复用 Buffer

writeStaged 在循环外创建一个 Buffer 与 Encoder，在每次编码前 Reset。这样相邻记录可以复用应用层缓冲容量，避免每次从零准备一个新的暂存对象。它比直接输出多了一层存储，所以不应把“复用”当成无条件更快的结论。

Buffer.Bytes 返回的是借用底层存储的切片。同步写完后再 Reset 是本例的所有权边界；若要把数据交给异步消费者，必须复制成独立字节，或者把整个缓冲区的所有权转移并等消费结束后才能重用。少一次复制不能以数据被下一轮覆盖为代价。

把复用风险分开处理

Reset 不等于擦除敏感内容，也不释放底层容量。长期对象或池化场景需要单独考虑保留策略；丢弃一个大 Buffer 也只是让它有机会被回收，不保证进程内存立即下降。本文示例把缓冲对象限定在一次函数调用里，没有建立跨租户共享池。

不要为了减少字节就顺手关闭 HTML 转义。SetEscapeHTML 改变的是转义行为，需要由实际输出上下文决定；它不是一个可以忽略安全语义的通用性能开关。缩进同样应由格式需求决定，别在对比时让两组输出配置不同。

解释内部边界并记录优化依据

官方公开实现中的 Encoder.Encode 仍有内部编码缓冲；把它接到网络 writer，不意味着一个巨大对象会按字段零缓冲发送。应用层减少中间结果，与标准库内部是否分配是两个问题。内部实现可以演进，不能把当前实现细节当作永久 API 保证。

记录优化时，保留 Go 工具链、数据类型、记录大小分布、是否缩进与转义、writer 类型、错误比例和并发度。在自己的性能评估中比较每操作分配次数、分配字节以及常驻内存；没有测量前，只陈述删掉了哪层应用数据，不宣称性能提升百分比。

把 Encoder 放进全局变量就能少分配吗？

它绑定具体 writer，还带有可变状态；全局复用容易跨请求串数据。应先围绕一个明确输出目标安排生命周期。

最终接口需要独立 []byte，怎么办？

这时保存最终字节本来就是需求。可以避免中途转字符串，但不能通过返回即将复用的 Buffer.Bytes 来伪装成独立结果。

技术依据：Encoder 官方文档、Buffer 官方文档、官方编码实现。