Go regexp.Longest 怎样改变重复匹配的选择

我在整理日志字段规则时遇到过一个很容易误判的现象：同一个起点既能匹配短片段，也能匹配长片段，但 Go 的默认选择不一定是最长结果。regexp.Compile 得到的 Regexp 默认采用 leftmost-first；调用 Regexp.Longest() 后，后续搜索会改为 leftmost-longest，在同一个最早起点上优先取更长的匹配。

Longest 改变的是这个 Regexp 对象后续搜索的选择规则，不是把任意正则都变成完整 POSIX 引擎。判断是否需要它，最直接的办法是比较匹配的起点、终点和长度。

出现短匹配时先做快速判断

最容易误判的是把“左起始”理解成“最长”。Go 文档把 regexp.Compile 的默认语义称为 leftmost-first：匹配从输入中尽可能早的位置开始；如果同一个起点存在多个候选，则选择通常回溯搜索会优先找到的那个。它并不承诺在这里直接取最长字符串。

第一组基线指标应该是匹配起点、匹配终点和匹配长度。起点相同而长度不同，才是 Longest 可能改变选择的场景；如果候选从不同位置开始，Longest 也不会把更晚的起点提到前面。

用 a(|b) 看 Longest 的直接变化

官方文档使用了一个很小但很有代表性的例子：表达式 a(|b)，输入字符串是 ab。默认规则从第一个字符开始，并优先得到 a；调用 Longest 后，起点仍然是第一个字符，但同一起点下会选更长的 ab。

package main

import (
	"fmt"
	"regexp"
)

func main() {
	// 这个表达式既能在第一个字符结束，也能继续匹配 b。
	re := regexp.MustCompile(`a(|b)`)
	input := "ab"

	// 默认是 leftmost-first，同一起点优先采用先遇到的候选。
	fmt.Printf("默认匹配：%q\n", re.FindString(input))

	// Longest 会修改这个 Regexp，让后续搜索采用 leftmost-longest。
	re.Longest()
	fmt.Printf("Longest 匹配：%q\n", re.FindString(input))
}

默认匹配："a"
Longest 匹配："ab"

这里最早起点没有变化，变化的是终点和长度：长度从 1 变成 2。Longest 不是从全文里找最长字符串，而是在最早起点的候选集合里取最长。

把选择差异记录成可解释的指标

如果正则用于协议字段、日志前缀或配置片段，不要只记录一个布尔值。把 FindStringIndex 返回的起止下标和切片长度一起记录，排查时可以回答：起点是否一致、终点是否向后移动、长度是否确实增加。

package main

import (
	"fmt"
	"regexp"
)

func main() {
	// 同一个表达式分别代表默认策略和 Longest 策略。
	defaultRE := regexp.MustCompile(`a(|b)`)
	longestRE := regexp.MustCompile(`a(|b)`)
	longestRE.Longest()

	input := "ab"
	for name, re := range map[string]*regexp.Regexp{
		"默认": defaultRE,
		"Longest": longestRE,
	} {
		// 下标是字节偏移；长度帮助定位“同起点、不同终点”。
		index := re.FindStringIndex(input)
		if index == nil {
			fmt.Printf("%s：未匹配\n", name)
			continue
		}
		match := input[index[0]:index[1]]
		fmt.Printf("%s：起点=%d，终点=%d，长度=%d，文本=%q\n", name, index[0], index[1], len(match), match)
	}
}

这组指标不是性能基准，而是语义基线。对同一输入分别保留默认对象和 Longest 对象，还能避免调试时忘记 Longest 已经改变了对象状态。

Longest 不等于 CompilePOSIX

两者都可能出现在“左最长”讨论里，但用途并不相同：

• Regexp.Longest() 是已有 Regexp 的配置方法，改变该对象未来搜索的匹配偏好。
• regexp.CompilePOSIX 限制为 POSIX ERE 语法，并直接使用 leftmost-longest 语义。
• 当存在多个左最长候选、但子匹配选择不同的时候，Go 的选择方式与 POSIX 对子表达式逐级取长的规则并不完全相同。

如果需求只是保留现有 Go 正则语法，同时让同一起点优先取长，可以考虑 Longest；如果需求来自严格 POSIX ERE 语法或兼容规范，应从表达式语法和子匹配规则一起评估。

配置方法不能和并发使用混在一起

Go 文档明确指出，Regexp 通常可以被多个 goroutine 并发使用，但配置方法 Longest 是例外：它会修改对象，不能与其他方法并发调用。实践中应在对象发布到共享位置之前完成配置。

package main

import "regexp"

// newRecordRegexp 在返回共享对象前完成匹配策略配置。
func newRecordRegexp() *regexp.Regexp {
	// 先编译，再配置；调用方拿到后只执行并发安全的搜索方法。
	re := regexp.MustCompile(`record:\s*(.+)`)
	re.Longest()
	return re
}

如果同一业务既需要默认选择又需要最长选择，不要让不同调用方随意修改一个全局 Regexp。更清晰的做法是提前构造两个对象，分别命名为默认策略和 Longest 策略；只有确实需要复制配置状态时，才结合 Regexp.Copy 的语义重新设计对象生命周期。

处理完成后留下这张选择表

判断可以压缩成一句话：先确认最早起点是否固定，再看同一起点是否有更长候选，最后确认子匹配和语法兼容是否比“取最长”更重要。这样 Longest 就是一个明确的语义开关，而不是遇到短匹配时的盲目补丁。

常见误区

Longest 会从全文中找最长的匹配吗？

不会。它仍然优先选择最早的匹配起点，只在这个起点的候选中偏好更长的匹配。

调用 Longest 后，已经得到的匹配会自动变化吗？

不会。它改变的是这个 Regexp 对象未来的搜索；已经保存的字符串、下标或子匹配不会被回写。

Longest 和 CompilePOSIX 可以互相替代吗？

不能直接替代。前者配置已有对象的匹配偏好，后者限制 POSIX ERE 语法并改变匹配语义；如果关心子匹配规则，必须按具体规范分别评估。

Regexp.Longest 能和搜索方法同时调用吗？

不应这样做。搜索对象通常支持并发使用，但 Longest 属于修改配置的方法，应在共享前完成。

参考文档

• Regexp.Longest：https://pkg.go.dev/regexp#Regexp.Longest
• Regexp.Compile：https://pkg.go.dev/regexp#Regexp.Compile
• Regexp.CompilePOSIX：https://pkg.go.dev/regexp#Regexp.CompilePOSIX
• Regexp.Copy：https://pkg.go.dev/regexp#Regexp.Copy