Go x/text/transform Reset 为什么不能随意放在分块循环内部

在 golang.org/x/text/transform 中，Reset 表示“这条逻辑流已经结束，清空 Transformer 的内部状态”，不是“当前 chunk 处理完了，顺手清一下”。如果一个文本、编码或规范化过程被拆成多个输入块，那么这些块仍属于同一条流，应该交给同一个 Transformer 连续处理；只有逻辑流结束、剩余输出已经冲刷，或者对象明确交回复用池时，才适合调用 Reset。

官方地址：https://pkg.go.dev/golang.org/x/text/transform

Reset 清的是流状态，不是分块边界

Transformer 接口同时提供 Transform 和 Reset。前者返回写入目标的字节数与消耗的源字节数，后者重置实现内部的状态。字符可能跨越输入块边界，某些变换也可能暂时没有足够的源字节完成输出，所以“本轮循环结束”与“逻辑流结束”不是同一件事。

官方文档对 Transform 的约定是：调用方要先处理已经产生的 nDst，再根据 nSrc 记录已经消耗的源数据，最后再判断错误。ErrShortSrc 说明源数据不足以完成当前变换，通常应等待下一块数据，而不是马上重置：

type Transformer interface {
    // Transform 处理一部分输入，并可能在内部保留跨块状态。
    Transform(dst, src []byte, atEOF bool) (nDst, nSrc int, err error)

    // Reset 结束当前逻辑流，清除实现保存的状态。
    Reset()
}

因此，分块循环里最重要的判断不是“这一块有没有读完”，而是“这一条逻辑流有没有结束”。只要后面还会把同一流的字节交给 Transformer，就不能把 Reset 当作循环尾部清理动作。

为什么在 chunk 循环内 Reset 会丢状态

假设输入被切成 chunk1、chunk2 和 chunk3。第一块的末尾可能只包含一个尚未完成的字节序列，Transformer 会先消费能够确定的部分，并留下等待后续输入的状态。如果循环每次都执行 Reset，第二块到来时，Transformer 已经忘记第一块留下的上下文。

这种错误有时不会立刻报错：纯 ASCII 或恰好没有跨边界的文本仍然可能输出正常，直到某次切块把一个多字节字符、组合序列或编码单元拆开，才出现替换字符、缺失输出或边界错误。下面的写法保留同一个 Transformer，直到整个输入结束：

func writeChunks(dst io.Writer, chunks [][]byte) error {
    // 每条逻辑流只创建一个 Transformer，不能按 chunk 重新开始。
    t := transform.Chain(norm.NFD)
    w := transform.NewWriter(dst, t)

    for _, chunk := range chunks {
        // Write 可以暂存尚未完成变换的字节，等待下一块继续处理。
        if _, err := w.Write(chunk); err != nil {
            return err
        }
        // 这里不要调用 t.Reset；当前流还没有结束。
    }

    // Close 负责把 Writer 中剩余的变换结果冲刷到 dst。
    if err := w.Close(); err != nil {
        return err
    }

    // 只有确认这条流已结束，且 t 不再被 w 使用时，才允许复用它。
    t.Reset()
    return nil
}

这段代码的关键不在于把所有输入一次性拼接，而在于保持状态的所有权：同一条流的 chunk 共用一个 Writer 和一个 Transformer。如果下一条流使用同一个 Transformer，必须确保上一条流已经完成 Close，并且没有任何协程或包装器继续持有它。

NewWriter、Close 与 Reset 的顺序怎么排

transform.NewWriter 会在创建包装器时调用 Transformer 的 Reset，这适合把一个新逻辑流交给 Writer。之后的 Write 可以多次接收分块数据，文档明确指出，不足以完成变换的字节会留到下一次写入；Close 则负责转换剩余字节。

可以把对象生命周期理解成三个边界：

如果不需要手动复用 Transformer，最简单的做法是让 Writer 独占它，并在一条流完成后一起释放。只有在明确的对象复用场景中，才需要在最后再调用 Reset；Reset 的位置应该跟“所有权交接”绑定，而不是跟“循环迭代”绑定。

正确与错误的放置位置

把两种写法放在一起，差异就很直观：正确方案让 atEOF=false 的块连续进入同一个状态机，最后一块再用 atEOF=true 或由 Writer.Close 冲刷；错误方案在每个块之后都清空 pending bytes，导致下一块无法接上上一块的上下文。

什么时候可以调用 Reset

• 可以调用：一条逻辑流已经结束，Writer 已经 Close，且没有未完成的消费者。
• 可以调用：准备把同一个 Transformer 明确交给下一条独立流，并由当前调用方独占。
• 不要调用：只是因为一次 Read 或一次 Write 返回了，就把 chunk 当成完整消息。
• 不要调用：仍有其他包装器、协程或调用者可能继续使用该 Transformer。

最后可以用一句话检查代码：如果下一次输入仍然属于同一条逻辑流，Reset 就太早；如果上一条流还没有冲刷完成，Reset 就更早。

常见问题

ErrShortSrc 是不是说明当前 chunk 无效？

不是。它通常表示当前源数据还不足以完成变换，调用方要结合已经消耗的 nSrc 处理，并等待同一逻辑流的后续输入。

每个 chunk 都新建一个 Transformer 可以吗？

只有当每个 chunk 本身就是独立完整的逻辑消息时才可以。若 chunk 只是网络读取或文件读取产生的分片，新建或 Reset 都会切断跨块状态。

Close 之后还要 Reset 吗？

不一定。若 Transformer 随 Writer 一起丢弃，不需要额外 Reset；若要复用同一个 Transformer，先完成 Close，再确认没有使用者，最后 Reset。