Go regexp.Regexp.FindReaderIndex 如何定位流式文本匹配：字节区间、UTF-8 边界与读取策略

处理日志或命令输出时，输入往往不是一个完整字符串，而是一个只能逐个字符读取的 io.RuneReader。这时可以用 regexp.Regexp.FindReaderIndex 找到最左侧匹配，但返回值不是“第几个字符”，而是 UTF-8 编码后的字节区间。

FindReaderIndex 返回 [开始字节位置, 结束字节位置)；它适合定位流式输入，却不能把返回下标直接当作 rune 序号，而且函数可能为了确认匹配而继续读取。

先把 FindReaderIndex 的定位方式说清楚

正则表达式本身只负责匹配，定位方法还要回答“位置以什么单位计算”。FindStringIndex 面向字符串，FindReaderIndex 面向 io.RuneReader，但二者都把结果表达成字节区间。若输入是 告警: 磁盘 92%，中文字符占用多个字节，m[0] 不等于人眼看到的第几个字符。

返回的第二个值是排他边界，因此原始字节可以用 data[m[0]:m[1]] 取出匹配文本。没有匹配时返回 nil，不要只判断切片长度后就把空结果当成成功。

一个可复现的流式读取例子

下面的例子用 strings.NewReader 提供 ReadRune，模拟日志流中查找连续数字。为了验证下标含义，再用同一份 UTF-8 字符串转换成字节切片取值。

package main

import (
    "fmt"
    "regexp"
    "strings"
)

func main() {
    input := "告警: 磁盘 92%"
    re := regexp.MustCompile(`[0-9]+%`)
    m := re.FindReaderIndex(strings.NewReader(input))
    if m == nil {
        fmt.Println("no match")
        return
    }
    data := []byte(input)
    fmt.Printf("byte index: %v, match: %q\\n", m, data[m[0]:m[1]])
}

这里的可见成功状态是输出一个两元素区间，并打印 92%。如果把区间改成 rune 数组下标，中文前缀会导致越界或截取出错误内容；正确做法是保持同一份 UTF-8 字节数据。

适合它的压力：输入不能一次性装进字符串

当数据来自解码器、文件或自定义字符流，调用方可能只希望保留读取接口，而不是先把全部内容读入内存。此时 FindReaderIndex 负责从当前位置寻找最左匹配，返回的仍然是从输入开头累计的 byte index。

要注意一个容易漏掉的契约：文档明确说它可能 arbitrarily far 地读取输入，即使返回的匹配已经确定。读取器如果连接着网络或有副作用，调用前应确认多读是可以接受的；需要精确控制读取窗口时，应先把边界内数据读入缓冲区，再使用 FindIndex。

两个反例：下标单位和读取边界混在一起

把字节下标当成 rune 下标

这是最常见的错误。m[0] 和 m[1] 可以直接切原始 UTF-8 字节，但不能直接切 []rune。如果确实需要字符位置，应在明确的字符序列上重新计算，而不要改写正则方法的返回值含义。

把读取器当成可重复查询对象

FindReaderIndex 会消耗读取器。第二次查询通常从上一次读取后的当前位置开始，不能期待它自动回到输入开头。需要多次不同模式匹配时，先缓冲内容通常更容易测试，也更容易给出稳定的错误日志。

上线前的判断清单

• 是否确认 m[0]:m[1] 对应的是字节区间，并且结束位置排他？
• 输入含中文或 emoji 时，是否用原始 UTF-8 字节切片取匹配？
• 读取器被消耗、且可能发生 arbitrarily far 读取，是否在接口设计中明确？
• 是否需要重复扫描或严格窗口；若需要，是否改为先缓冲再用 FindIndex？

常见问题

FindReaderIndex 没找到时返回什么？

返回 nil。应先判断是否为 nil，再读取下标。

为什么中文会让下标看起来偏大？

因为返回值按 UTF-8 字节计算，一个中文字符通常占三个字节；它不是 rune 数量。

怎样避免读取器被多读？

如果多读会触发昂贵操作或越过协议边界，先在调用方建立有限缓冲区，再对字节切片执行正则匹配。

小结

FindReaderIndex 的价值在于直接对流式字符读取接口做最左匹配；它的代价是调用方必须接受字节下标、读取器消耗和可能的超前读取。把这三个边界写进测试，流式日志定位就不会被“字符位置”和“字节位置”的错觉带偏。