Go x/text/secure/bidirule 流式双向文本为什么要等结尾再确认

Go x/text/secure/bidirule 的流式检查需要等到一个标签真正结束，才能确认它的最终结尾是否满足 Bidi Rule。中途没有报错，只说明目前处理的输入没有触发已确定的失败条件；后续字符仍可能改变结尾或引入不允许的组合。使用 transform.Writer 时，必须检查 Close 的错误；直接调用 Transform 时，必须正确传递 atEOF 并处理最后一次调用。

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

先区分输入片段与完整标签

考虑分块上传一个标签的场景：网络包边界只是传输边界，不能替代字段结束标志。我更倾向于先把“读到多少”与“是否可以提交”分开建模，这样调用点不容易把某次 Write 成功误当成完整文本已通过。

Bidi Rule 包含首字符、允许的方向类别、结尾类别和数字类别组合等约束。RTL 标签的结尾涉及 R、AL、EN 或 AN 类字符及其后的 NSM；因此合法的中间位置字符不一定能作为最终结尾。尚未完整到达的 UTF-8 字符又是另一个等待更多字节的原因。两种情况都说明，当前缓冲区耗尽并不自动等于逻辑输入结束。具体规则参见 RFC 5893 第2节。

最小配方：暂存输出并检查 Close

下面的配方面向已有字节片段的有界标签。所有片段属于同一个逻辑字段，每次调用创建独立检查器；仅当写入与 Close 都成功时返回暂存内容。示例没有连接真实网络，也不提供虚构运行输出。

package labelcheck

import (
    "bytes"
    "fmt"
    "io"

    "golang.org/x/text/secure/bidirule"
    "golang.org/x/text/transform"
)

// CheckChunks 仅在整个标签检查结束后交付暂存结果。
func CheckChunks(chunks [][]byte, maxBytes int) ([]byte, error) {
    if maxBytes  maxBytes-total {
            return nil, fmt.Errorf("标签超过大小上限")
        }
        total += len(chunk)
    }

    var staged bytes.Buffer
    w := transform.NewWriter(&staged, bidirule.New())
    for _, chunk := range chunks {
        n, err := w.Write(chunk)
        if err != nil {
            // 失败时丢弃暂存内容，不向业务调用方交付部分结果。
            return nil, fmt.Errorf("检查标签片段: %w", err)
        }
        if n != len(chunk) {
            return nil, io.ErrShortWrite
        }
    }
    // 必须显式检查结束错误，不能用忽略返回值的 defer 代替。
    if err := w.Close(); err != nil {
        return nil, fmt.Errorf("完成标签检查: %w", err)
    }
    return append([]byte(nil), staged.Bytes()...), nil
}

这段代码把传入片段视为完整输入，因此能在循环结束后 Close。如果片段来自仍未结束的连接，应由协议字段长度、记录分隔或其他明确的消息边界决定何时完成，而不是因短暂没有新数据就结束。maxBytes 是本例的应用限制，不代表任何域名标准长度要求。调用方原有的片段内存也不在暂存缓冲区的限制之内。

手动调用时保留状态和未消费字节

需要自行管理缓冲区时，Transform 的 nSrc 表示本次已消费的源字节，nDst 表示已产生的输出。先记账，再处理错误；未消费的输入要保留。ErrShortSrc 表示还不足以完成当前处理，不能直接视作文本非法；ErrShortDst 表示输出空间不足。具体失败可通过 bidirule.ErrInvalid 区分。

atEOF=false 表示后面可能还有属于同一输入的字节；最后一批数据才使用 true。若前面已把所有字节消费完，仍应让检查器获知真正结束，不能以“最后一次没有新数据”为由省略结束处理。也不能把每一个传输块都当作独立输入设置 atEOF=true。

同一标签分块时保留同一个 Transformer；不同标签使用新实例或在完整结束后 Reset。每块都 Reset 会丢失跨块方向类别信息；把多个独立标签直接串到一个实例里则会混合约束。完整字符串场景可以选择 ValidString，避免自行维护流式计数。包文档说明了有状态 Transformer 的复用要求。

把确认结果绑定到业务提交

我会优先把检查器接到暂存区，而不是直接接到不可撤回的发送接口。Writer 可能在最终错误出现前已经写出前缀，Close 失败不会替外部系统撤回这些字节。若必须处理较大输入，可以采用有界临时存储与独立提交动作；资源关闭、删除和错误传播由该实现负责。不要把 Bidi 检查完成解释成完整 IDNA 处理或通用内容审核完成。

按输入规模选择实现

短小且已完整取得的字段，用完整输入接口通常更直观。持续到达的数据可使用 Writer 或 Reader 包装器，但仍需把逻辑标签边界、完整读取和错误处理放到调用约定中。Reader 提前停止读取同样可能使调用方没有观察到后续错误。

每次 Write 都成功，为什么 Close 仍可能失败？结束时才能确定最后的状态；分块写入没有承诺未来后缀也满足约束。Close 还负责处理可能缓冲的数据。

使用 defer w.Close() 就够了吗？不够。成功返回之前必须显式观察错误，并据此决定是否交付结果；仅把 Close 放进忽略返回值的 defer 会漏掉失败。

可以把检查过的前缀先返回吗？可以设计专门的预览通道，但它不能携带“整个标签通过”的含义。需要完整通过才能生效的业务，应等最终确认后再提交。

接口资料：transform 的缓冲、计数与 Writer 约定。