Go regexp.Regexp 怎样读取字面前缀

如果一个正则表达式的所有匹配都必须从同一段固定文本开始，可以调用 Regexp.LiteralPrefix 读出这段前缀。它返回 prefix 和 complete：前者是任何匹配都必须拥有的字面开头，后者表示这段前缀已经覆盖整个正则。注意，拿到前缀只说明“可以先做一道便宜的筛选”，不能代替正则本身的最终匹配。

官方地址：https://pkg.go.dev/regexp#Regexp.LiteralPrefix

先看 LiteralPrefix 的两个返回值

package main

import (
    "fmt"
    "regexp"
)

func main() {
    samples := []string{`^/api/[^/]+$`, `^/api/`, `^foo$`, `foo|bar`}

    for _, expression := range samples {
        re := regexp.MustCompile(expression) // 示例表达式固定，初始化失败直接暴露配置错误。
        prefix, complete := re.LiteralPrefix()
        fmt.Printf("%-16s prefix=%q complete=%v\n", expression, prefix, complete)
    }
}

这里的结果应按“静态推导”理解：^/api/[^/]+$ 的前缀是 /api/，但并不完整；^/api/ 的前缀也是 /api/，通常也不会把后续语义当成完整正则。^foo$ 可以得到 foo 和完整标记；foo|bar 没有一个能覆盖所有分支的共同字面开头时，前缀可能为空。

complete 不是“本次输入匹配成功”，而是“字面前缀已经组成整个正则”。真正判断输入是否满足表达式，仍然调用 MatchString 或其他匹配方法。

固定前缀不等于固定字符串

“字面前缀”只描述表达式的共同开头。正则后面仍可能有字符类、量词、分组或结束锚点，所以应把它当作候选过滤条件。

package main

import (
    "fmt"
    "regexp"
)

func main() {
    re := regexp.MustCompile(`^/api/users/[0-9]+$`)
    prefix, complete := re.LiteralPrefix()

    candidates := []string{"/api/users/42", "/api/orders/42", "/api/users/me"}
    for _, value := range candidates {
        // 前缀先排除明显无关项，完整语义交给正则判断。
        if prefix != "" && len(value) 

示例中的 /api/users/42 会通过最终匹配，/api/orders/42 会在前缀筛选阶段被排除，/api/users/me 虽然拥有相同前缀，仍会由正则的数字约束拒绝。这就是前缀判断和完整匹配必须分开的原因。

如果前缀包含非 ASCII 字符，不要把“字符数”直接当成字符串切片的字节位置来推导复杂逻辑。最稳妥的做法是使用 strings.HasPrefix 做前缀关系判断，或者让 Regexp.MatchString 负责最终语义；不要为了手写切片而复制一套编码规则。

把前缀判断接到调用方分支

LiteralPrefix 适合放在接口分类、日志路由、规则索引等“先分桶、后精确判断”的位置。调用方可以为有前缀的表达式建立候选桶，但不能把空前缀误当作可匹配全部输入的业务结论。

package main

import (
    "fmt"
    "regexp"
)

func classify(re *regexp.Regexp, input string) bool {
    prefix, complete := re.LiteralPrefix()
    if complete {
        // 完整字面表达式可以走等值判断，但仍返回统一的匹配语义。
        return input == prefix
    }
    if prefix != "" && len(input) >= len(prefix) && input[:len(prefix)] != prefix {
        return false // 明显不可能匹配的输入无需进入正则引擎。
    }
    return re.MatchString(input) // 前缀命中后仍要检查量词、字符类和锚点。
}

func main() {
    re := regexp.MustCompile(`^event/[a-z]+$`)
    fmt.Println(classify(re, "event/created"))
    fmt.Println(classify(re, "audit/created"))
}

这个分支只承担“是否值得继续尝试”的职责。若表达式来自配置文件，建议在加载阶段编译并保存前缀信息；若配置可热更新，则在替换正则和前缀元数据时使用同一个不可变快照，避免两者不属于同一版本。

三个容易误读的边界

• 空前缀：它表示没有可供所有匹配共享的稳定字面开头，不表示正则为空，也不表示一定匹配失败。
• 完整标记：它描述表达式结构，不描述某个输入的匹配结果；输入比较仍要使用等值判断或统一匹配函数。
• 元字符：前缀是按正则语义解析后的字面文本。不要把原始表达式字符串直接截断后当作安全前缀，尤其要留意转义、分组和分支。

如果只是想判断字符串是否以某段文本开头，直接使用 strings.HasPrefix 更清晰；只有当表达式本身是运行时配置、且需要把正则语义接入候选分流时，LiteralPrefix 才有明显价值。

常见问题

LiteralPrefix 会执行匹配吗？ 不会。它读取已编译正则的结构信息，返回可作为候选筛选的字面前缀；输入是否匹配仍由具体匹配方法决定。

为什么明明写了前缀，返回值还是空？ 先检查是否存在分支、可选前缀或会改变起始字符的表达式结构。前缀必须对所有可能的匹配都成立，只有某一条分支拥有的文本不能算共同前缀。

记住一句话：LiteralPrefix 负责告诉你“所有候选从哪里开始”，MatchString 负责告诉你“这个输入是否真的符合规则”。