Go 问答：regexp.Regexp.Longest 为什么会改变匹配结果，路由规则怎么选左最长

写路由前缀匹配时，最容易忽略的不是正则语法，而是“同一个起点到底取哪一个结果”。Go 的 regexp 默认采用 leftmost-first：先找到最靠左的匹配，再按表达式搜索顺序返回结果；调用 Regexp.Longest 后，才会在同一起点优先取更长的匹配。

如果规则存在前缀包含关系，例如 a 和 ab 同时能匹配输入 ab，默认结果可能是 a；只有明确调用 Longest，才会稳定选择 ab。它改变的是匹配策略，不是把普通正则变成另一种语法。

默认匹配为什么先返回较短的结果

先看官方示例压缩后的最小场景：

package main

import (
    "fmt"
    "regexp"
)

func main() {
    re := regexp.MustCompile(`a(|b)`)
    fmt.Println(re.FindString("ab"))

    re.Longest()
    fmt.Println(re.FindString("ab"))
}

两次输入都是 ab。第一次输出 a，因为表达式在最左起点先走到了空分支；调用 Longest 后，第二次输出 ab。这不是随机行为，也不是 Go 把表达式重写了，而是 FindString 使用的选择策略变了。

Longest 改变的是同一起点的取舍

把“左最长”拆开看会更清楚：第一步仍然寻找最靠左的起点；第二步只在这个起点的多个候选中选择更长的结果。因此它不会让一个更靠右但更长的匹配越过更靠左的匹配。

例如输入是 xab，如果最早起点只能从 a 开始，那么 Longest 会在这个起点比较候选；它不会为了寻找更长字符串而先跳到后面的字符。这个边界很适合写在测试用例里，否则看到“变长了”就容易误以为它是全局最长搜索。

配置方法不能混入并发初始化

官方文档把 Regexp.Longest 列为配置方法。一个已经被多个 goroutine 调用的 Regexp，不要在运行中再切换策略。更稳妥的做法是在初始化阶段完成配置，然后只读使用；如果同一表达式需要两种语义，就分别编译两个对象。

路由前缀有包含关系时，默认结果可能误判

假设服务把路径前缀交给正则判断，规则里同时有 /api/ 与 /api/admin/。如果后续代码拿到的是第一个匹配结果，并把它当成路由归属，那么短前缀先命中就可能让管理路由进入普通 API 分支。

package main

import (
    "fmt"
    "regexp"
)

func main() {
    pattern := regexp.MustCompile(`/api/|/api/admin/`)
    route := pattern.FindString("/api/admin/users")
    fmt.Println(route)
}

这里先别急着给所有正则都加 Longest。如果规则顺序本身就是业务优先级，改变语义可能造成另一类回归。先确认候选是否真的共享同一最左起点，以及调用方是否需要“最长前缀”而不是“第一条规则”。

需要最长前缀时怎么写得可验收

如果业务约定是同一起点优先选择更长前缀，可以把配置和搜索写在同一个初始化函数中，并让测试直接锁住返回值：

func routePrefix() *regexp.Regexp {
    pattern := regexp.MustCompile(`/api/|/api/admin/`)
    pattern.Longest()
    return pattern
}

func pickRoute(re *regexp.Regexp, route string) string {
    return re.FindString(route)
}

验收重点不是看 Longest 是否被调用，而是验证输入 /api/admin/users 的返回结果是否符合业务预期，并补一个只有短前缀的输入。这样可以区分“最长语义生效”和“表达式刚好只有一条可匹配规则”。

func TestPickRoute(t *testing.T) {
    re := routePrefix()
    if got := pickRoute(re, "/api/admin/users"); got != "/api/admin/" {
        t.Fatalf("got %q", got)
    }
    if got := pickRoute(re, "/api/users"); got != "/api/" {
        t.Fatalf("got %q", got)
    }
}

迁移前后要检查哪些边界

表达式顺序是否承载业务优先级

默认 leftmost-first 下，表达式分支的顺序可能影响结果；迁移到 Longest 后，同一起点的较长候选会被优先选择。凡是依赖分支顺序的规则，都要逐条确认。

是否把最左起点误解成全局最长

测试应同时覆盖不同起点的候选，明确业务到底要求“最早位置”还是“最长文本”。如果需求是全局扫描后找最长字符串，Longest 本身并不直接表达这个目标。

是否在共享对象运行中切换配置

把 Longest 放到启动初始化阶段，避免请求处理期间修改同一个 Regexp。需要两种行为时，保留两个独立对象，名字上直接体现用途。

选择这两种语义的速查结论

规则顺序就是优先级、短匹配先命中有明确意义时，保留默认语义，并用测试固定输入和输出。规则代表层级前缀、同一起点必须选择更具体的较长项时，在初始化阶段调用 Longest，然后针对长短重叠、不同起点和空分支补回归测试。

如果只是为了让路由“看起来更具体”，不要只改这一行配置。先把匹配结果、分支选择和失败兜底串起来看，确认最长前缀确实是业务规则。

相关问题

Longest 会让正则支持 POSIX 的全部子表达式规则吗？

不会。它只调整 Regexp 后续搜索的匹配选择；如果需要 POSIX 语法和对应语义，应从 CompilePOSIX 的文档与测试入手。

已经并发使用的正则还能调用 Longest 吗？

不应在并发使用期间切换。初始化时配置完成后，普通匹配方法才适合被多个 goroutine 复用。

判断是否该用 Longest，最后只问一个问题：同一起点的多个候选中，最长结果是不是业务明确要求的那个结果？答案确定，再把它写进初始化代码和回归测试。