Go regexp贪婪匹配吞掉多个字段时的收敛写法

解析一行带分隔符的日志时，最容易踩的坑不是正则写错，而是边界没有写出来。比如输入 user=alice|role=admin|trace=7f2a，模式 user=(.+)\|role=(.+) 会让第一个 .+ 尽可能向右吃字符，结果字段范围变得难以预测。

官方参考地址：https://pkg.go.dev/regexp

Go regexp 的默认匹配是 leftmost-first。字段有明确分隔符时，优先用排除分隔符的字符类；只有结束标记不固定时，才使用非贪婪量词，并通过子匹配数量和边界用例回归。

步骤一：先复现贪婪组吞字段

先不要急着给表达式加更多括号，固定一行输入，直接打印完整匹配和每个子组。FindStringSubmatch 返回的第 0 项是整体匹配，后面才是捕获组，这个顺序要在测试中固定下来。

package main

import (
    "fmt"
    "regexp"
)

func main() {
    input := "user=alice|role=admin|trace=7f2a"
    // 贪婪组会优先向右扩展，直到后面的条件能够成立。
    greedy := regexp.MustCompile(`user=(.+)\|role=(.+)`)
    // 非贪婪组先在更靠左的位置尝试结束。
    lazy := regexp.MustCompile(`user=(.+?)\|role=(.+)`)

    fmt.Printf("贪婪: %#v\n", greedy.FindStringSubmatch(input))
    fmt.Printf("非贪婪: %#v\n", lazy.FindStringSubmatch(input))
}

这两个表达式都可能匹配成功，但它们表达的意图不同：贪婪组适合“尽可能多取”，非贪婪组适合“遇到后续固定标记就停”。如果字段真正由竖线切开，继续依赖回退过程并不稳妥。

步骤二：已知分隔符就写进字符类

如果字段不能包含竖线，最直接的方案是让字符类明确排除它。这样模式不需要“先吃多一点，再回退”，而是从匹配规则上禁止跨过边界。

package main

import (
    "fmt"
    "regexp"
)

func main() {
    input := "user=alice|role=admin|trace=7f2a"
    // [^|]+ 表示连续读取非竖线字符，字段不会跨过分隔符。
    re := regexp.MustCompile(`^user=([^|]+)\|role=([^|]+)\|trace=([^|]+)$`)
    groups := re.FindStringSubmatch(input)
    if len(groups) != 4 {
        // 组数量不对时不要继续按下标取值，避免把格式错误当成正常数据。
        fmt.Println("格式不符合预期")
        return
    }
    fmt.Printf("user=%s role=%s trace=%s\n", groups[1], groups[2], groups[3])
}

这里的 ^ 和 $ 把输入整体纳入约束，三个字符类分别对应三个字段。若允许空字段，把 + 改为 *，但要同步增加空值测试，否则缺失值和空值会被混淆。

步骤三：边界不固定时再用非贪婪量词

有些文本没有稳定分隔符，例如字段后面可能跟着 、 等固定标记。这时可以用非贪婪量词把结束标记交给后半段：

package main

import (
    "fmt"
    "regexp"
)

func main() {
    input := "request-id=7f2aok"
    // .*? 尽量少取内容，直到后面的固定标签能够匹配。
    re := regexp.MustCompile(`(.*?)`)
    match := re.FindStringSubmatch(input)
    if len(match) == 2 {
        fmt.Println("meta:", match[1])
    }
}

非贪婪不等于“自动知道业务边界”。如果输入里可能出现嵌套标签、转义标记或缺失结束标记，正则就可能不是合适的解析器。Go 的 regexp 使用 RE2 语法，不能依赖某些回溯引擎才有的高级特性，模式要保持可读且可证明。

步骤四：用子匹配结果做回归检查

匹配成功只说明某个路径成立，不代表字段已经正确拆开。至少准备正常输入、空字段和缺失分隔符三组样本，并检查子组数量与内容：

如果表达式长期复用，可以在包级初始化时用 MustCompile；如果模式来自配置或用户输入，则使用 Compile 返回错误，不要用 panic 把配置问题带入服务启动。

步骤五：收敛写法的迁移清单

1. 先标出每个字段的真实结束条件，再决定是字符类还是非贪婪量词。
2. 给整体表达式加锚点或固定前缀，避免在长文本中误命中另一段内容。
3. 用 FindStringSubmatch 检查第 0 组和捕获组，不只断言布尔结果。
4. 输入允许空值时明确选择 *，并在业务层区分空值与缺失字段。
5. 遇到嵌套、转义或跨行结构时，及时迁移到状态机、JSON/XML 解析器或手动扫描。

常见问题

Go regexp 有懒惰匹配吗？

有，RE2 语法支持非贪婪的 *?、+? 等形式，但它仍依赖后续模式提供可识别的结束条件。

为什么不用所有字段都写成 .*?？

因为没有稳定结束标记时，非贪婪组可能匹配空串或过早结束；已知分隔符用字符类更直观，也更容易做边界测试。

什么时候应该放弃正则？

当数据具有嵌套层级、转义规则或需要精确错误位置时，专用解析器或小型状态机通常比继续堆叠表达式更容易维护。