Go regexp.Regexp.Longest 怎样让匹配优先选择最长结果

解决办法是对已经编译的 *regexp.Regexp 调用一次 Longest()，再进行后续搜索。它只改变这个 Regexp 对象的匹配偏好，不改变正则语法，也不能在其他 goroutine 同时搜索时修改对象。

官方地址：https://pkg.go.dev/regexp@go1.27.3#Regexp.Longest

Regexp.Longest 解决的是哪种匹配歧义

Go 的普通 regexp.Compile 会返回一个可复用的 *Regexp。官方规则是先找最早开始的位置，再按 leftmost-first 语义选择结果；这和“从最早位置开始后，再选最长结果”不是一回事。

可以用一个故意存在短分支和长分支的表达式观察差异。下面的 a(|b) 在字符串 ab 的位置 0 都能开始匹配，但空分支可以让默认策略先得到短结果；调用 Longest() 后，后续搜索会偏向完整的 ab。

最小示例：在第一次搜索前设置 Longest

Longest 没有返回值，它直接修改当前 Regexp 对象的匹配偏好。因此习惯上应在构造完成、交给其他函数或 goroutine 之前调用它。示例用 Compile 保留错误处理，适合表达式来自配置文件的情况：

package main

import (
	"fmt"
	"regexp"
)

func main() {
	re, err := regexp.Compile(`a(|b)`)
	if err != nil {
		// 配置表达式可能不合法，先返回错误，不继续使用空对象。
		panic(err)
	}

	short := re.FindString("ab")
	re.Longest()
	long := re.FindString("ab")

	// Longest 只影响后续搜索，同一个起点会优先保留更长候选。
	fmt.Printf("默认=%q，Longest=%q\n", short, long)
}

这个例子要观察的是选择规则，不是“正则变得更贪婪”这么简单：两种策略都先看最早起点，区别只在同一起点存在多个候选时如何选。对真正的业务表达式，应该把短分支、长分支和子表达式边界写进测试样例，避免仅凭一次输出推断全部语义。

Longest 与 CompilePOSIX 不要混为一谈

Regexp.Longest 与 regexp.CompilePOSIX 都会让读者想到“最长匹配”，但它们解决的问题层级不同。Longest 作用在已编译的普通 RE2 表达式上，改变同一起点下整个匹配的选择偏好；CompilePOSIX 则限制为 POSIX ERE 语法，并采用 POSIX 规定的左端最长语义。

我在实际排查时会先问两个问题：表达式是否依赖 Go regexp 支持的语法扩展？是否需要 POSIX 对子表达式逐级最大化的规则？只需要前者的最长候选时，用普通 Compile 后调用 Longest 更直接；必须遵守 POSIX 语法和选择规则时，使用 CompilePOSIX 更准确。

package main

import (
	"fmt"
	"regexp"
)

func choose(pattern, input string, posix bool) (string, error) {
	var (
		re  *regexp.Regexp
		err error
	)
	if posix {
		// POSIX 模式同时约束语法和子表达式的选择规则。
		re, err = regexp.CompilePOSIX(pattern)
	} else {
		// 普通模式先编译，再按需要切换整个匹配的最长偏好。
		re, err = regexp.Compile(pattern)
		if err == nil {
			re.Longest()
		}
	}
	if err != nil {
		return "", fmt.Errorf("编译表达式失败：%w", err)
	}
	return re.FindString(input), nil
}

不要为了得到“更长字符串”就无条件使用 POSIX 版本。它的语法接受范围和普通 regexp 不完全相同，而且 POSIX 对子表达式的规则也可能让捕获组结果与预期不同。文章的主题是一个边界选择：先确认表达式语言和子匹配要求，再决定 API。

调用时机和并发复用边界

官方文档特别强调，Regexp 除了配置方法外，可以安全地被多个 goroutine 并发使用；Longest 属于配置方法，不能和其他方法并发调用。最稳妥的做法是把表达式构造、错误处理和 Longest 设置集中在初始化阶段，之后只读复用。

func buildMatcher(pattern string, longest bool) (*regexp.Regexp, error) {
	// 编译阶段完成全部可变配置，返回后只把对象交给并发搜索者。
	re, err := regexp.Compile(pattern)
	if err != nil {
		return nil, err
	}
	if longest {
		// 不能把这次配置调用放到正在 Match 的 goroutine 中。
		re.Longest()
	}
	return re, nil
}

如果同一个表达式既需要默认语义又需要最长语义，不要在共享对象上来回切换。可以分别编译两个 Regexp，或者使用 Copy 形成独立配置；关键是让每个对象从发布给调用方开始就保持稳定。这里的“稳定”是并发边界，不是要求每次匹配都重新编译。

什么时候值得启用最长匹配

• 适合：同一起点可能有多个候选，业务希望先保留最长 token、最长前缀或最长字段值，并且表达式本身仍属于普通 Go regexp 语法。
• 谨慎：表达式含有多个捕获组，业务依赖每个子表达式的精确结果；应为捕获结果单独写测试，不要只断言整个字符串。
• 不适合：只是想让普通量词“多匹配一些”，却没有同一起点的候选歧义。此时先检查量词、分组和输入边界，调用 Longest 可能掩盖表达式设计问题。
• 需要 POSIX 时：选择 CompilePOSIX，并接受它的语法限制和子表达式选择规则。

我现在会把 Longest() 当成一个明确的匹配策略开关，而不是修复所有正则结果不符合预期的万能按钮。先写出“同一起点的短候选与长候选”，再决定默认语义、Longest 还是 POSIX，排查会快很多。

常见问题

调用 Longest 后，所有匹配都会变成长结果吗？

不会。它只影响同一起点存在多个候选时的选择；如果只有一个候选，或候选起点不同，Longest 不会把匹配凭空扩展到其他起点。

Longest 可以在每次 FindString 前切换吗？

不建议。它修改 Regexp 对象的配置，不能与搜索方法并发调用。应在初始化阶段完成设置；需要两种策略时使用两个独立对象。

Longest 和贪婪量词是同一件事吗？

不是。量词决定表达式内部允许匹配的范围，Longest 决定同一最早起点的候选如何选择。两者可能共同影响结果，但不能相互替代。