Go x/text/transform Chain 怎样组合多个文本转换器

Go 的 transform.Chain(t1, t2, t3) 会按参数顺序组合文本转换器：前一个转换的输出交给后一个。处理字符串可使用 transform.String，处理持续输入可使用 transform.NewReader。组合之前要确认相邻转换器使用的编码与规则相容，不能把顺序当作随意排列。

官方文档入口：https://pkg.go.dev/golang.org/x/text/transform。我会先用能区分规则先后的输入分析组合含义，再把它封装为每次独立任务新建的转换链。本文以宽度折叠、下划线映射和 NFC 规范化为例，不虚构实际排障经历或执行结果。

输出与预期不同时先看组合顺序

假设规则要求将全角拉丁字符折叠到规范宽度，把 ASCII 下划线改为空格，并将结果规范化为 NFC。核心问题是全角下划线 ＿：它在宽度折叠前不是 ASCII 下划线，因此只识别 '_' 的映射函数必须放在 width.Fold 后面，才能处理折叠产生的下划线。

我会把“看起来相同”和“码点相同”分开讨论。将映射放前面时，全角下划线先被保留，随后才折叠成 ASCII 下划线；将 Fold 放前面时，它可以被后面的映射改为空格。这是顺序的语义差异，不是并发调度或性能差异。

把每个转换器的输入约定写清楚

本例使用 UTF-8 字符串。width.Fold 负责规范宽度，runes.Map 负责指定码点映射，norm.NFC 负责最终规范化；Chain 只负责组合，不会推断业务规则。图中的输入契约、Chain、width.Fold、runes.Map、norm.NFC、结果文本六个节点就是这组职责。

width.Fold 文档说明它映射到规范宽度；norm 文档列出了各规范化形式。我把 NFC 放在本例最后，是为了让最终结果满足选定形式，而不是声称所有组合都必须如此排列。

用工厂函数组合并处理返回错误

下面的工厂函数集中定义组合，字符串入口另外拒绝非法 UTF-8，并返回转换错误。把错误处理保留在外层，日后加入可能报错的编码转换器时不必更改函数契约。

package textchain

import (
    "fmt"
    "unicode/utf8"

    "golang.org/x/text/runes"
    "golang.org/x/text/transform"
    "golang.org/x/text/unicode/norm"
    "golang.org/x/text/width"
)

// NewTextChain 为一个独立输入创建转换链。
func NewTextChain() transform.Transformer {
    separators := runes.Map(func(r rune) rune {
        // Fold 后的 ASCII 下划线统一变成空格。
        if r == '_' {
            return ' '
        }
        return r
    })
    // 参数顺序属于规则定义：宽度、映射、最终规范化。
    return transform.Chain(width.Fold, separators, norm.NFC)
}

// NormalizeText 返回完整转换结果，错误时不提交部分结果。
func NormalizeText(input string) (string, error) {
    if !utf8.ValidString(input) {
        return "", fmt.Errorf("输入不是有效 UTF-8")
    }
    output, _, err := transform.String(NewTextChain(), input)
    if err != nil {
        return "", fmt.Errorf("组合文本转换失败: %w", err)
    }
    return output, nil
}

以 Ａ＿B 为例，按本例规则推导的预期文本为 A B。本文没有运行示例。实际使用时将依赖锁定到与项目工具链兼容的版本，并确保接入方同意这组有损转换规则。

transform.String返回结果、已消费的源字节数和错误，调用前会 Reset 转换器。这里用完整字符串入口，因此不把中间消耗位置当成业务字符数量；如果返回错误，示例主动丢弃部分文本。

流式输入要由同一个实例持续处理

当输入来自文件时，不要对任意字节分块分别调用 transform.String 再拼起来：那会把每块当作独立输入，跨块字符或规范化上下文可能被拆开。我会为整个输入创建一个 NewReader，让它持续持有当前链；每个新文件再创建一条新链。

图中的任务实例拥有转换链，转换 Reader 包装输入 Reader 并引用转换链，io.Copy 读取转换 Reader、写入输出 Writer。这些是组件关系，不是运行轨迹；Chain 不负责关闭文件或提交业务事务。

// 此函数与前面的工厂函数放在同一包，文件需导入 io 和 fmt。
// 输入必须由调用方提供为 UTF-8；本入口不做全流预读检查。
func NormalizeStream(dst io.Writer, src io.Reader) error {
    reader := transform.NewReader(src, NewTextChain())
    // 读取到底才能处理流尾；错误时 dst 可能已有部分输出。
    if _, err := io.Copy(dst, reader); err != nil {
        return fmt.Errorf("流式转换失败: %w", err)
    }
    return nil
}

流式入口与字符串入口的输入策略不同：它假设调用方已提供 UTF-8，不会为了预先判断合法性读取整个流。需要严格拒绝非法编码时，应另行设计流式输入检查策略。输入与输出文件的 Close、缓冲输出的 Flush 仍由调用方负责；错误也不会自动撤销已经写出的字节。

接入时怎样判断问题属于哪一层

我会先对照输入契约：原始数据是否真是 UTF-8，码点是否与映射条件一致；再对照参数顺序：前一规则产生的新字符是否应由后面的规则处理；最后看状态归属：是否对同一流反复创建链，或把同一个有状态实例交给多个并发任务。

Chain 会自动并行执行吗？不会，它表达参数顺序的组合。不要因组件数量多就假定会增加并行度，也不要在没有测量时宣称比逐段字符串处理更快。

ErrShortSrc、ErrShortDst 是业务失败吗？在直接调用底层 Transform 时，它们分别表示输入暂不足或输出空间不足，需要结合 nSrc、nDst 与 atEOF 处理。普通 Reader 使用方式应读取到结束并处理返回错误，避免自行只调用一次 Transform 就认定完成。

字符串和文件能共享同一个全局链吗？本例选择用工厂为独立任务建链，避免把多个输入的状态混在一起。需要复用时必须了解各组件状态并控制独占与重置，不要把复制接口变量当成复制内部状态。