Go x/text/unicode/norm 分块 NFC 为什么不能独立处理每个小块

Go x/text/unicode/norm 不能对任意小块分别 NFC 后直接拼接，因为组合与重排可能跨越块边界。即使每块都是合法 UTF-8，而且各自已经是 NFC，拼接结果也未必是 NFC。解决办法是把完整文本一次处理，或使用同一个流式包装器保留未结束片段；内存中的增量构建可以使用 norm.NFC.Append，并保留它返回的完整结果。

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

分块边界为什么不是正规化边界

设第一块以字母 o 结束，第二块以组合分音符 U+0308 开始。两块分别正规化时，第一块看不到后面的组合符；把各自结果简单连接，不能得到与对整体执行 NFC 相同的表示。这是字符关系的问题，不能靠把缓冲区从几百字节改大一些来保证消失。

下面用代码表达这个反例，展示的是规则推导，没有附加实际运行日志。Go 字符串不会自动正规化，字节相等也不能直接代表规范等价。

// 两个片段分别完整，但组合关系跨越它们的接缝。
left := "o"
right := "\u0308"
separate := norm.NFC.String(left) + norm.NFC.String(right)
whole := norm.NFC.String(left + right)
// separate 与 whole 表示的文本规范等价，字节表示却不同。

仅按 rune 切块可以避免切断 UTF-8 编码，却仍可能切开组合序列。网络 Read 的次数、固定字节数和应用自定义的数组边界，都不天然具备正规化独立性。Go 官方正规化说明也指出，两个 NFC 字符串连接后不保证仍为 NFC。

三种方案应该怎样选择

面对文件、上传内容等字节来源，我会先考虑流式包装器，把块边界细节交给库。对于已经在内存里的短字段，整体 String 通常更容易阅读。这是实现复杂度的取舍，不代表哪一种方案在所有负载下更快；没有基准数据时不做性能排名。

用同一个 Writer 接收连续字节

这个完整函数接收属于同一个逻辑文本的多个字节片段，不为每块创建新 Writer。输入额度在处理前限定，函数在 Close 成功后才返回结果。代码用于说明组织方式，不声称已在本机运行。

package textnfc

import (
    "bytes"
    "fmt"
    "io"

    "golang.org/x/text/unicode/norm"
)

// JoinNFC 把所有片段作为一份连续文本正规化。
func JoinNFC(chunks [][]byte, maxInput int) (string, error) {
    if maxInput  maxInput-total {
            return "", fmt.Errorf("输入超过上限")
        }
        total += len(chunk)
    }

    var dst bytes.Buffer
    w := norm.NFC.Writer(&dst)
    for _, chunk := range chunks {
        n, err := w.Write(chunk)
        if err != nil {
            return "", fmt.Errorf("写入正规化器: %w", err)
        }
        if n != len(chunk) {
            return "", io.ErrShortWrite
        }
    }
    // Close 完成可能缓冲的尾部，错误必须传回调用方。
    if err := w.Close(); err != nil {
        return "", fmt.Errorf("完成正规化: %w", err)
    }
    return dst.String(), nil
}

片段可以是任意字节切分，流式包装器承担跨调用的缓冲。逻辑输入本身是否允许无效 UTF-8，应由应用另定编码策略；不要把正规化当成完整的输入合法性检查。上例限制的是总输入，不是精确的输出内存预算，NFC 也不承诺输出字节数总是减少。大输入需要额外选择有额度的输出目的地。

如果使用 Reader，就持续读取同一个 NFC.Reader 包装器，并观察最终错误；不要每次底层 Read 都重新包装。直接调用 Transform 时，调用方还要处理 nSrc、nDst、未消费字节以及 atEOF，维护成本明显更高。

追加式处理为什么要保留已有尾部

// out 初始为空，此后始终保留 Append 返回的正规化结果。
var out []byte
out = norm.NFC.AppendString(out, "o")
out = norm.NFC.AppendString(out, "\u0308")
// 使用 out 的最终版本，不缓存追加前的尾部字节或假设长度只增不减。

norm 的 Append 与内置 append 语义不同：它会考虑旧结果和新输入之间的正规化关系。其前提是 out 为空、nil，或者已经符合当前 Form。若已有前缀来自其他来源，应先正规化；不要把任意未处理字节当作已正规化 out。

这里的字符串片段按完整 UTF-8 文本组织。任意原始字节流可能切断编码时，优先使用流式包装器，避免自己拼凑编码与正规化的缓冲约定。累计 out 不意味着历史前缀全部不可变，跨接缝的尾部可能重新组合；因此不应把每次新增切片直接作为不可撤回的独立输出。

独立处理与并行处理的适用条件

Form 文档把可独立处理的切分位置定义为 boundary：在该处两侧分别正规化再连接，与整体正规化一致。需要分片并行时，应先解决边界识别；NextBoundary 的 atEOF=false 可能因信息不足而返回 -1，这时应保留数据等待更多输入，不能把 -1 当作切片索引。Form 接口文档给出了边界和追加方法的约定。

每块 IsNormal 都为 true，拼起来可以省略处理吗？不能。它只回答该块自身是否符合该 Form，不能证明相邻接缝不存在组合关系。

把缓冲区扩大到 4 KB 就安全吗？不能保证。任意固定切点仍可能落在组合序列内部，正确性应来自边界语义或连续处理接口。

两份互不相关的字段能共用一个 Writer 吗？不应把独立字段当作同一文本连续写入，否则可能引入原本不存在的跨字段关系。每份逻辑文本独立完成正规化，再按业务规则保存或组合。