Go regexp.FindAllStringIndex 的下标怎么用：UTF-8 字节偏移与切片边界

写文本高亮或抽取关键词时，regexp.FindAllStringIndex 看起来会直接返回匹配位置，但中文一出现，很多人就会把它当成字符下标，随后在切片处遇到乱码或越界。关键点只有一个：Go 正则返回的区间是字符串底层字节的半开区间 [start, end)，不是第几个汉字。只要先确认边界，再决定按字节切还是按 rune 切，问题就能稳定解决。

先看一个中文匹配结果到底返回什么

我们准备一段英文、中文、数字混排的测试字符串，用正则匹配其中连续的中文词汇，输出时同时打印匹配到的字节区间、对应内容和这段内容的字节长度：

package main

import (
    "fmt"
    "regexp"
)

func main() {
    text := "Go语言很实用，正则也很实用"
    re := regexp.MustCompile(`语言|正则`)

    for _, loc := range re.FindAllStringIndex(text, -1) {
        start, end := loc[0], loc[1]
        fmt.Printf("[%d:%d] %q bytes=%d\n", start, end, text[start:end], end-start)
    }
}

这里的 text[start:end] 可以安全拿到匹配内容，因为 start 和 end 都是正则针对同一个 UTF-8 字符串计算出来的字节边界。输出中的区间不会告诉你“第 2 到第 4 个汉字”，它只告诉你从底层字节数组的哪个位置开始、到哪个位置结束。

为什么英文和中文会让下标看起来不连续

Go 的字符串是只读字节序列，UTF-8 中文通常占 3 个字节，而 ASCII 英文占 1 个字节。对同一个字符串分别使用 len 和 utf8.RuneCountInString，得到的就是两套不同的计数：

package main

import (
    "fmt"
    "unicode/utf8"
)

func main() {
    s := "Go语言"
    fmt.Println(len(s))                     // 8：字节数
    fmt.Println(utf8.RuneCountInString(s)) // 4：字符数
}

FindAllStringIndex 选择字节下标，是为了让结果可以直接用于 s[start:end]。如果它返回字符序号，调用方反而还要把字符位置重新换算成字节位置才能切片。这个设计对原样提取很方便，但对“第几个字符前插入标记”就要多一步转换。

按字节截取和按字符定位不是一回事

日常开发里几种常见需求的处理逻辑不要混在一起：

一个常见错误是把 loc[0] 当作 rune 下标：

runes := []rune(text)
loc := re.FindStringIndex(text)
// 错误示例：loc[0] 可能已经大于 len(runes)
// wrong := string(runes[loc[0]:loc[1]])

修复方式不是简单把两个数字强行塞进 []rune。如果业务确实要求字符区间，应把字节起点转换成该字符串前缀的 rune 数量：

func byteRangeToRuneRange(s string, start, end int) (int, int) {
    if start  len(s) {
        return 0, 0
    }
    runeStart := utf8.RuneCountInString(s[:start])
    runeEnd := utf8.RuneCountInString(s[:end])
    return runeStart, runeEnd
}

这个函数的前提是 start 和 end 落在合法 UTF-8 字符边界上。正则匹配的结果满足这个前提；如果区间来自手工计算或外部协议，仍然要先验证。

三个容易漏掉的边界

空匹配会返回什么

允许空匹配的正则可能返回起止位置相同的区间。处理时不要默认 end > start，否则可能漏掉合法的零长度边界。若业务只关心实际文本片段，可以显式跳过 start == end。

负数 n 不等于只找一个

FindAllStringIndex(s, n) 中，n 表示找出全部匹配，n == 0 表示不返回结果，正数则限制最多返回多少个。这个参数只控制数量，不会改变下标的字节语义。

非法 UTF-8 字节串要谨慎

Go正则处理字符串时底层还是直接操作字节数据。如果输入来自文件读取或者网络请求，先确认整体解码流程没问题；把一段可能损坏的字节强行转成字符串后再用rune统计，得到的字符数量很可能和调用方预期不一致，不要用“字符数相等”代替内容有效性检查。

把结果封装成不容易误用的小函数

团队内部的公共代码里可以保留正则返回的原始字节区间，同时封装一个只读的匹配结构，让调用方不必重复编写边界判断逻辑：

type Match struct {
    StartByte int
    EndByte   int
    Text      string
}

func matches(s string, re *regexp.Regexp) []Match {
    locs := re.FindAllStringIndex(s, -1)
    out := make([]Match, 0, len(locs))
    for _, loc := range locs {
        if len(loc) != 2 || loc[0]  len(s) {
            continue
        }
        out = append(out, Match{StartByte: loc[0], EndByte: loc[1], Text: s[loc[0]:loc[1]]})
    }
    return out
}

调用方若要在原文中高亮，使用 StartByte 和 EndByte；若要在 UI 上显示字符位置，再单独计算 rune 位置。两种坐标都保留，比在函数内部偷偷转换后只返回一个模糊的“位置”更可靠。

常见问题

FindAllStringIndex 返回的是字符下标吗？

不是。它返回的是UTF-8字节下标，得到的区间可以直接用于同一个字符串的字节切片操作。

中文匹配结果为什么经常是 3 的倍数？

常见中文字符在UTF-8编码里占3个字节，所以返回的区间长度经常表现为3的倍数，这不是正则额外追加了字符。

什么时候应该改用 FindAllStringSubmatchIndex？

需要同时拿到捕获组的位置时使用它。它同样返回字节区间，只是每个整体匹配项和对应的捕获组都会生成一对起止下标。

最后的检查清单

• 执行切片操作前确认区间来自同一个原始字符串。
• 把字节下标交给字符串切片逻辑，把字符位置交给rune层处理。
• 对空匹配、负数 n、非法 UTF-8 输入分别写测试。
• 需要做高亮或者替换操作时保留原始字节区间，避免多次转换造成偏移错误。