Go bufio.Reader.ReadRune 解码非法 UTF-8 的替换字符边界

处理文本流时，bufio.Reader.ReadRune 的关键不是只看返回的 rune，而是同时看 rune、size 和 err。遇到非法 UTF-8，它会消耗一个字节，返回 unicode.ReplacementChar（U+FFFD）和 size=1；这条路径本身不等于底层 I/O 出错。循环应先判断 err，再根据 rune 与 size 决定是否拒绝输入。

先看 ReadRune 的返回三元组

官方接口把一个 UTF-8 字符和它占用的字节数一起返回。ASCII 字符的 size 是 1，中文通常是 3，其他合法 Unicode 字符可能是 2 或 4。只有在没有字符可读时，才会进入错误处理；非法编码则按一个错误字符消费一个字节。

把非法输入和 EOF 分开处理

下面的循环把判断顺序固定下来：先处理非空错误，再识别 RuneError 加 size=1 的非法字节。示例选择严格拒绝策略，适合协议字段、配置文件或需要稳定字符集的导入任务。若业务允许替换，可以把 return 改成写入替代字符，但要保留计数和偏移记录。

package main

import (
    "bufio"
    "errors"
    "fmt"
    "io"
    "strings"
    "unicode"
)

func readUTF8Strict(input string) error {
    reader := bufio.NewReader(strings.NewReader(input))
    for offset := 0; ; {
        r, size, err := reader.ReadRune()
        if err != nil {
            // EOF 表示输入正常结束，其他错误需要交给调用方。
            if errors.Is(err, io.EOF) {
                return nil
            }
            return fmt.Errorf("读取位置 %d 失败: %w", offset, err)
        }
        if r == unicode.ReplacementChar && size == 1 {
            // 非法 UTF-8 只消耗一个字节，不能把它当成普通 U+FFFD。
            return fmt.Errorf("位置 %d 存在非法 UTF-8", offset)
        }
        offset += size
    }
}

这里的 offset 是已经消耗的字节数，不是字符下标。这个区别很重要：如果前面有中文，字符数与字节偏移就不同。严格模式也只是在发现第一个坏字节时停止，不会把后续数据当作已经验证过。

若输入可能包含合法的 U+FFFD，单靠返回值无法区分它和非法编码生成的替换字符。此时应在数据进入 Reader 前保留原始字节，并用 utf8.Valid 或 utf8.ValidString 做整段校验；不要在替换后再尝试恢复原值。

UnreadRune 与生产循环的几个边界

UnreadRune 只允许回退最近一次由 ReadRune 完成的读取，而且应紧邻调用。中间插入 Peek、Discard 或其他读取方法后再回退，都会破坏这个假设。若只是为了检查前缀，不要先 ReadRune 再长期依赖回退，应该重新设计缓冲或使用明确的字节校验。

对网络流和文件流，还要区分“读到一个替换字符”和“读操作失败”。前者可以是数据内容问题，后者是 I/O 生命周期问题；监控、重试和告警的归属不同。建议记录字节偏移、来源标识和策略结果，但不要把原始内容直接写入日志。

常见问题

RuneError 一出现就一定是坏 UTF-8 吗？

不一定。输入本身可能合法地包含 U+FFFD。结合 size=1 才能识别 ReadRune 对非法编码的常见返回形态；需要绝对区分时保留原始字节并预校验。

ReadRune 返回 RuneError 时为什么 err 还是 nil？

因为 UTF-8 解码失败被当作字符层面的替换结果，而不是底层 Reader 的 I/O 错误。业务是否拒绝它，应由调用方的文本策略决定。

size 可以直接当成字符数量吗？

不可以。size 是该 rune 消耗的 UTF-8 字节数；需要字符数量时单独计数，需要原始位置时累计 size。