Go 正则怎样选择最长左优先匹配

如果你在 Go 的正则表达式里遇到“同一个位置既能匹配短分支，也能匹配长分支”，默认的 regexp 行为不是简单地取最长字符串，而是采用左优先规则。需要改变这个选择方式时，先编译正则，再在开始搜索前调用 Regexp.Longest()。

一句话记忆：默认模式优先选择最早开始、并按表达式分支优先级得到的匹配；调用 Longest 后，才会在同一起点的候选中优先选择更长的匹配。它改变的是已有 Regexp 实例后续搜索的匹配语义，不是修改正则文本。

默认模式为什么可能返回较短结果

Go 的 regexp.Compile 使用 RE2 语法，并采用 leftmost-first，也就是“最早开始”优先；如果多个候选从同一个位置开始，则按照正则搜索通常会先遇到的分支选择结果。因此，分支写法本身会影响默认结果。

下面的模式把 b 放在一个可选分支里。输入是 ab，从索引 0 开始既有 a，也有 ab，但默认模式会先得到较短的 a：

package main

import (
	"fmt"
	"regexp"
)

func main() {
	// 空分支排在 b 前面，用来展示默认的分支优先选择。
	re := regexp.MustCompile(`a(|b)`)

	// 默认模式从最早位置开始，并沿着优先分支得到 a。
	fmt.Println(re.FindString("ab"))
}

a

这里的“左优先”不要理解成“永远只取左边一个字符”。它首先比较匹配起点；只有起点相同，才会受到默认分支选择规则的影响。把表达式改成 ab|a，默认结果也可能不同，因为分支顺序已经发生变化。

用 Regexp.Longest 切换为最长左优先

Longest 是 *regexp.Regexp 的方法。它不会接受新参数，也不会返回新的正则对象，而是修改当前实例，让这个实例后续的搜索偏向 leftmost-longest：先找最早的起点，再在该起点的候选中取更长的匹配。

package main

import (
	"fmt"
	"regexp"
)

func main() {
	// 先编译一次，后面在同一个实例上切换匹配语义。
	re := regexp.MustCompile(`a(|b)`)

	// 先观察默认模式的结果。
	fmt.Println("默认:", re.FindString("ab"))

	// Longest 影响之后的搜索，不改变表达式文本。
	re.Longest()
	fmt.Println("最长:", re.FindString("ab"))
}

默认: a
最长: ab

从使用方式看，最重要的是把配置动作放在搜索之前：

1. 使用 Compile 或 MustCompile 创建 Regexp。
2. 如果业务需要同一起点的最长候选，立即调用 Longest()。
3. 之后再调用 FindString、FindAllString 或其他搜索方法。

如果同一个正则对象只承担默认语义和最长语义两种不同任务，不建议在搜索过程中反复切换。更清楚的做法是分别编译两个实例，并在实例命名上体现用途，例如 tokenFirst 与 tokenLongest。

Longest 和 CompilePOSIX 不是同一个开关

这两个入口都可能让人联想到“最长匹配”，但职责不同：

CompilePOSIX 还会限制可用的正则语法；它不是把普通 Compile 返回的实例“改成 POSIX 模式”。此外，当多个最长匹配的子匹配也存在差异时，Go 文档说明普通 Compile 加 Longest 与 POSIX 在子匹配优先级上并不完全等价。因此，不能仅凭“都包含 longest”就把两者互换。

共享 Regexp 前要先完成配置

Regexp.Longest 会修改正则实例。官方文档特别说明，调用它时不能与该实例的其他方法并发执行。因此，推荐把它放在初始化阶段，完成后再把实例交给并发搜索代码。

package main

import "regexp"

var tokenLongest = func() *regexp.Regexp {
	// 初始化阶段完成 Longest，避免运行期与搜索并发改同一个实例。
	re := regexp.MustCompile(`go(|lang)`)
	re.Longest()
	return re
}()

func matchToken(input string) string {
	// 这里只读已配置完成的实例，可表达“共享搜索、初始化配置”的边界。
	return tokenLongest.FindString(input)
}

这段写法的重点不是使用全局变量，而是“配置和使用分阶段”。如果正则需要动态生成，可以在构造函数中完成 Longest 后再返回；如果同时需要两种语义，就返回两个彼此独立的实例，而不是在请求处理函数里临时切换。

用最小对照用例固定选择规则

正式接入前，准备一个能同时产生短、长候选的字符串，再对比默认实例和最长实例。测试重点是结果边界，而不是把所有正则 API 都覆盖一遍：

package regexpdemo

import (
	"regexp"
	"testing"
)

func TestMatchMode(t *testing.T) {
	// 同一起点的 a 与 ab 用来区分两种匹配语义。
	defaultRE := regexp.MustCompile(`a(|b)`)
	longestRE := regexp.MustCompile(`a(|b)`)
	longestRE.Longest()

	// 明确写出业务希望保留的两个结果，避免只凭肉眼判断。
	if got := defaultRE.FindString("ab"); got != "a" {
		t.Fatalf("默认匹配 = %q，想要 a", got)
	}
	if got := longestRE.FindString("ab"); got != "ab" {
		t.Fatalf("最长匹配 = %q，想要 ab", got)
	}
}

如果你的表达式包含捕获组、重复量词或多个候选分支，还要单独确认子匹配结果。尤其是在从普通 Compile 迁移到 CompilePOSIX 时，不应只检查整个匹配字符串，还应检查业务真正读取的每个子组。

迁移时可以直接照着这张清单

1. 先确认问题是“同一起点想取更长候选”，而不是想改变正则语法。
2. 保留 Compile 时，按需在初始化阶段调用 Longest。
3. 不要把 Longest 当成 POSIX 兼容开关；确实需要 POSIX 语义时再评估 CompilePOSIX。
4. 把默认与最长实例分开命名，避免调用方不知道当前对象的匹配规则。
5. 对短分支、长分支、捕获组和无匹配情况各写一个小用例，再交给并发代码使用。

常见问题

调用 Longest 后需要重新 Compile 吗？

不需要。Longest 直接修改当前 Regexp 实例，后续搜索会使用新的选择语义；表达式文本和已编译结构不会因为这次调用而变成另一条正则。

Longest 会让所有匹配都变长吗？

不会。它只在同一个最早起点存在多个候选时偏向更长者；如果没有更长候选，结果不会凭空扩展，也不会改变匹配起点。

普通正则和 POSIX 正则怎么选？

优先按项目已有语法和兼容要求选择。只想在 Go 的普通正则上调整同一起点的选择，使用 Compile 加 Longest；需要 POSIX ERE 语法与对应子匹配规则时，才从 CompilePOSIX 开始设计。