Go regexp.Regexp.LiteralPrefix 能否提前筛选请求：字面前缀与完整匹配边界

路由表里混着固定前缀和正则规则时，先用 regexp.Regexp.LiteralPrefix 做一次廉价筛选很有用，但它不能替代最终匹配。这个方法只回答“所有命中是否都带着同一个字面开头”，真正是否命中，仍要交给 MatchString。

prefix 适合做候选过滤，complete 只说明整个正则是否等价于这个字面字符串；只有 strings.HasPrefix 和 MatchString 都通过，才能把请求交给对应处理器。

LiteralPrefix 到底保证了什么

官方文档的定义很窄：它返回一个字面字符串，这个字符串必须出现在正则表达式每一次匹配的开头；第二个返回值为 true 时，说明这个字面字符串已经覆盖了整个正则。

例如 ^/api/orders/[0-9]+$ 的可用前缀是 /api/orders/，但它不是完整规则。/api/orders/42 可能命中，/api/orders/latest 仍然会被后续正则判断拒绝。

最小示例：固定前缀只负责缩小候选集

下面的 matchRoute 模拟一个按路径分发的规则。LiteralPrefix 得到 prefix 后，先用 strings.HasPrefix 排除明显无关的路径；通过预筛选的请求还要走 MatchString。

package main

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

func matchRoute(pattern, path string) bool {
    re := regexp.MustCompile(pattern)
    prefix, complete := re.LiteralPrefix()
    if complete {
        return path == prefix
    }
    if prefix != "" && !strings.HasPrefix(path, prefix) {
        return false
    }
    return re.MatchString(path)
}

func main() {
    pattern := `^/api/orders/[0-9]+$`
    for _, path := range []string{"/api/orders/42", "/api/orders/latest", "/web/orders/42"} {
        fmt.Println(path, matchRoute(pattern, path))
    }
}

输出应为：

/api/orders/42 true
/api/orders/latest false
/web/orders/42 false

这里的关键不是“前缀匹配更快”这句口号，而是两层判断职责不同：HasPrefix 只做候选过滤，MatchString 才解释数字区间、结尾锚点等正则语义。

三个容易误判的边界

空前缀不是“所有路径都能匹配”

包含可变开头、分支或锚点位置不适合提取固定字面串的表达式，prefix 可能是空字符串。此时不要用空前缀放宽路由；直接跳过 HasPrefix，让 MatchString 完成判断。

complete=true 仍然需要比较输入

如果正则本身就是 ^/health$，LiteralPrefix 可能返回 /health 和 true。这表示规则已经退化成一个完整字面串，代码可以用 path == prefix，但返回值不是“当前 path 已命中”的证明。

不要把前缀判断写成最终安全校验

/api/orders/latest 与 /api/orders/42 拥有同一个前缀。若只调用 strings.HasPrefix，就会把业务上不合法的 latest 交给数字 ID 处理器。固定前缀适合缩小候选，不能替换表达式。

把它放进真实路由表时怎么选

规则数量较多时，可以在启动阶段编译正则并保存 prefix、complete，请求到来后只做字符串预筛选和最终匹配。Regexp 可以被多个 goroutine 并发使用；不要在请求处理中反复 MustCompile，那是编译生命周期问题，与 LiteralPrefix 的语义无关。

相关问题

LiteralPrefix 会把前缀从输入路径中删掉吗？

不会。它只返回分析结果，不会修改正则，也不会修改输入字符串。

前缀为空时是否应该接受所有请求？

不应该。空前缀只说明没有可利用的固定开头，最终结果仍由 MatchString 决定。

只想判断固定字符串时还需要正则吗？

如果规则确实是完整字面串，直接比较字符串通常更清楚；是否保留正则要看规则表是否需要统一管理。

小结

LiteralPrefix 的价值是把正则规则拆出一个安全的候选过滤条件。记住 prefix 描述“必然的开头”，complete 描述“正则是否已经完整退化为这个字面串”，而 MatchString 才是最终答案。这样写路由分发，既不会把前缀筛选误当成正则校验，也能让规则表的意图更容易复查。