Go regexp.Longest 为什么会改变子表达式结果

regexp.Longest 改变的不是某个捕获组的“贪婪程度”，而是整个正则的匹配候选选择规则：默认选择最左位置上按分支优先得到的匹配；调用 Longest 后，仍先找最左起点，但会从该起点选择最长的整体匹配。整体候选一变，附属于它的子表达式结果自然也可能变化。

官方文档：https://pkg.go.dev/regexp

先复现：同一个表达式为什么返回两组结果

问题通常出现在带有可选分支的表达式里。下面的 a(|b) 可以在输入 ab 的同一位置得到两个整体候选：a 或 ab。默认模式先接受排在前面的空分支；Longest 则改为选择更长的整体候选。

package main

import (
    "fmt"
    "regexp"
)

func main() {
    // 空分支写在 b 前面，因此默认语义会先接受整体匹配 "a"。
    normal := regexp.MustCompile(`a(|b)`)
    fmt.Printf("default: %#v\n", normal.FindStringSubmatch("ab"))

    // Longest 必须在开始匹配前配置，它会选择同一起点的最长整体匹配。
    longest := regexp.MustCompile(`a(|b)`)
    longest.Longest()
    fmt.Printf("longest: %#v\n", longest.FindStringSubmatch("ab"))
}

捕获组不是被 Longest 单独延长了。真正发生的是：默认实例选中了整体候选 a，此时括号匹配空分支；Longest 实例选中了整体候选 ab，于是同一组括号对应 b。

定位原因：Longest 先改变整体匹配候选

可以把选择过程拆成两个判断维度。第一维永远是起点：匹配开始位置越靠左，优先级越高。第二维才区分模式：默认模式在这个起点上保留表达式分支的优先顺序；Longest 模式比较整体候选的终点，优先更长的那一个。

这也解释了一个常见误判：Longest 不会为了更长而跳过更早的起点。假设位置 2 有一个较短匹配、位置 5 有一个更长匹配，它仍会选择位置 2，因为“最左”先于“最长”。只有起点相同的候选才比较整体长度。

划清边界：它不会逐个最大化捕获组

官方文档特别说明：可能存在多个起点相同、整体长度也相同，但捕获组划分不同的结果。Go 在这些候选中选择类似回溯搜索首先找到的那一个，并不会依次最大化第一个、第二个捕获组。换句话说，Longest 保障的是整体匹配最长，不是每个子表达式都最长。

因此，若业务依赖某个捕获组的精确边界，不能只看到“最长”两个字就推断结果。最稳妥的做法是把存在歧义的输入写成表格测试，同时尽量用更明确的分支结构消除重叠。

修复方案：配置一次并隔离两种匹配语义

Regexp 的匹配方法通常可以被多个 goroutine 并发调用，但 Longest 属于配置方法：它会修改正则实例，官方明确要求不能与其他方法并发调用。不要在每次请求、每次解析或某个条件分支里动态切换。

安全做法是在初始化阶段完成配置，然后只读共享。如果同一套表达式同时需要默认语义和最长语义，准备两个独立实例。文档还指出，Copy 虽然已不再用于规避锁竞争，但在需要不同 Longest 设置时仍可能适用；新代码直接编译两个实例通常更直观。

复查清单：什么时候应该使用 Longest

• 协议字段、词法片段或文本切分明确要求“同一起点取最长整体片段”时，可以启用。
• 只想让某个捕获组更长时，不要启用；应改写该组及其相邻分支。
• 替换逻辑依赖 $1、命名组或索引范围时，先对歧义输入核对捕获结果。
• Regexp 会跨 goroutine 共享时，在发布实例前固定配置，运行期不再调用 Longest。
• 必须同时支持两种语义时，用两个实例明确表达用途，不让一个实例来回切换。

相关问题

Longest 会让所有量词都变成贪婪吗？

不会。它改变的是同一最左起点上整体候选的选择规则，不是逐个重写 *、+、? 或捕获组。

调用 Longest 后还能恢复默认模式吗？

公开 API 没有对应的关闭方法。需要默认语义时应保留或重新编译另一个实例。

为什么 MatchString 看不出差异？

MatchString 只返回是否存在匹配，不暴露整体文本和捕获组。要观察差异，应使用 FindString、FindStringSubmatch 或相应的 Index 方法。