Go regexp.FindReaderIndex 怎样在流式文本中定位匹配范围

处理日志流、网络响应或很大的文本时，我们经常不想先把所有内容读进一个字节切片，再调用正则。Go 的 regexp.Regexp.FindReaderIndex 可以直接接收 io.RuneReader，返回第一个匹配在输入中的字节起止位置。

它返回的是 []int{start, end}：匹配内容对应输入字节范围 [start:end]；找不到时返回 nil。但它可能为了判断匹配而继续从 Reader 读取，所以不要把返回下标误解成 Reader 已经停在 end 位置。

本文用一个流式文本场景说明如何取出匹配、如何处理 UTF-8 和无匹配结果，以及什么时候应该改用 FindIndex 或 MatchReader。

FindReaderIndex 返回的到底是什么

这个方法的签名是 FindReaderIndex(r io.RuneReader) []int。它只找最左侧的首个匹配，不返回全部匹配，也不返回子表达式位置。返回的两个数字是字节下标，不是 Unicode 字符编号。

因此，拿到结果后通常这样理解：

• loc == nil：输入中没有匹配；
• loc[0]：匹配开始的字节位置；
• loc[1]：匹配结束位置的后一字节；
• 匹配内容的字节区间是 source[loc[0]:loc[1]]。

用 Reader 定位首个匹配

示例把字符串包装为 strings.Reader。它实现了 io.RuneReader，便于先把区间语义讲清楚；真实项目中也可以传入实现同一接口的缓冲 Reader。

package main

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

func main() {
    source := "订单 A-102 已入库，订单 B-305 待拣货"
    re := regexp.MustCompile(`B-\d+`)

    // strings.Reader 同时保留原始字节内容，并实现 io.RuneReader。
    reader := strings.NewReader(source)
    loc := re.FindReaderIndex(reader)
    if loc == nil {
        // nil 表示没有匹配，不能直接访问 loc[0]。
        fmt.Println("没有找到订单号")
        return
    }

    // 下标是字节位置，因此可以在原始字符串上直接切片。
    fmt.Printf("范围=%v，内容=%q\n", loc, source[loc[0]:loc[1]])
}

这里的关键不是把 Reader 当成字符串游标，而是把它作为正则的输入来源；要切出匹配文本，仍需要一份可按字节下标访问的原始数据。若原始内容不能保留，就只记录范围或改用返回文本的 API。

为什么 UTF-8 文本要按字节下标切片

Go 的字符串底层是字节序列，FindReaderIndex 返回的也是字节位置。中文字符通常占用多个 UTF-8 字节，所以不要把 loc[0] 和 loc[1] 当作第几个字符。

package main

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

func main() {
    source := "状态：已完成；编号：A-102"
    re := regexp.MustCompile(`A-\d+`)

    // Reader 只负责提供输入；source 负责按返回的字节范围取内容。
    loc := re.FindReaderIndex(strings.NewReader(source))
    if loc == nil {
        fmt.Println("没有匹配")
        return
    }

    // 这是字节切片，不是按 rune 序号切片，所以不会截断中文前缀。
    matched := source[loc[0]:loc[1]]
    fmt.Printf("字节范围=%v，匹配=%s\n", loc, matched)
}

只要起止位置来自同一份原始输入，按 source[start:end] 取出的边界就是合法的 UTF-8 区间。若程序把文本转成 []rune 后再处理，就不能继续使用这组字节下标直接索引 rune 切片。

无匹配和空匹配分别怎么判断

无匹配时返回 nil，这是第一层判断。正则也可能匹配空字符串，此时返回的切片仍然存在，但 loc[0] == loc[1]。所以不要只用区间长度是否为零来判断“没有匹配”。

// 先判断 nil，再判断是否为空匹配。
loc := re.FindReaderIndex(reader)
switch {
case loc == nil:
    fmt.Println("没有匹配")
case loc[0] == loc[1]:
    fmt.Println("找到了空匹配")
default:
    fmt.Println("找到了非空匹配")
}

Reader 可能读过匹配末尾

官方文档特别提醒，FindReaderIndex 可能从 Reader 读取任意远的内容，甚至超过返回的匹配范围。原因是正则引擎需要继续观察输入，才能判断当前位置是否是最左侧匹配以及匹配是否已经结束。

这带来一个实际边界：如果 Reader 后面还有另一段协议、另一条消息或需要交给下一个解析器的数据，不能假设调用结束后这些字节仍然留在 Reader 中。需要可控的缓冲和回退时，可以让 Reader 自身提供缓冲能力，或在协议层先定义清晰的帧边界。

FindReaderIndex、FindIndex 和 MatchReader 怎么选

一个简单的决策顺序是：先判断输入是否已经完整缓冲；再判断是否真的需要下标；最后确认 Reader 后续内容是否属于同一帧。这样可以避免为了“省一次 ReadAll”而破坏后续协议的边界。

常见误区

• 把返回下标当成 rune 序号：它们是字节下标，中文文本尤其容易暴露这个错误。
• 不判断 nil 就读取 loc[0]：无匹配时会触发越界。
• 把 FindReaderIndex 当成只读取到匹配结束的扫描器：官方明确允许超前读取。
• 用空区间判断无匹配：空匹配也可能产生 start == end 的有效结果。

小结

FindReaderIndex 适合“输入来自 Reader，但我需要首个匹配字节范围”的场景。牢记三点即可：结果是字节区间，找不到返回 nil，Reader 可能读过匹配末尾。需要完整内容时保留同一份原始字节数据，需要跨协议边界时先做缓冲或分帧，再决定是否调用它。

相关问题

• FindReaderIndex 能返回所有匹配吗？不能，它只返回最左侧的首个匹配。
• 返回下标能直接切 rune 切片吗？不能，返回值按字节计数，应该作用于同一份字符串或字节切片。
• 只想知道是否匹配怎么办？优先考虑 MatchReader，不必维护下标。