Go regexp/syntax.Regexp.Simplify 怎样减少正则语法树冗余

当正则表达式来自配置文件、规则表或用户可编辑字段时，原始字符串很快会出现重复分支、无意义分组和多层量词。Go 的 regexp/syntax 可以先把文本解析为 Regexp 语法树，再用 Simplify 得到语义等价的更紧凑表示。它适合做规则整理和审计记录，但不能替代输入校验、匹配用例或性能测试。

最稳妥的接入方式是保留原始文本，解析成 syntax.Regexp 后调用 Simplify()，把化简结果作为可读的规范形态；真正交给 regexp 执行前，仍要单独处理解析错误、业务边界和回归用例。

官方文档：https://pkg.go.dev/regexp/syntax#Regexp.Simplify

把正则先变成可审计的语法树

先不要把配置文本直接丢给 regexp.Compile。对于需要展示、存档或比较的规则，保留原文可以回答“用户输入了什么”，而 Regexp 和它的 String() 结果可以回答“解析器把它理解成什么”。这两份材料各自有用途，不能只留下化简后的字符串。

package main

import (
    "fmt"
    "regexp/syntax"
)

func main() {
    // 原文保留给审计和回显，不要用化简结果覆盖它。
    const pattern = `(?:ab|ab|a(?:b|b))`

    // Perl 模式支持常见的非捕获分组语法，并返回可遍历的语法树。
    re, err := syntax.Parse(pattern, syntax.Perl)
    if err != nil {
        // 配置错误应在进入执行层前返回，避免把坏规则继续下传。
        fmt.Println("parse error:", err)
        return
    }

    // Simplify 返回语义等价的紧凑表示；这里仍保留原始文本。
    simplified := re.Simplify()
    fmt.Println("original:", pattern)
    fmt.Println("parsed:", re.String())
    fmt.Println("simplified:", simplified.String())
}

这里的关键不是把输出字符串当作“更正确的正则”，而是把它当成一种可读的规范表示。syntax.Parse 负责把文本转成语法树，Simplify 负责在语义不变的前提下整理树结构；如果解析失败，流程应该停在错误处理分支。

哪些冗余可以化简，哪些语义必须保留

重复分支和空操作通常是化简的好候选，例如两个完全相同的分支没有必要同时保留。可是“文本看起来相似”不等于“语义相同”：捕获组、字符范围、边界断言和量词范围都可能影响调用方得到的结果。判断依据应该是语法节点和匹配契约，而不是字符串长度变短。

func auditRegexp(re *syntax.Regexp, depth int) {
    if re == nil {
        return
    }

    // 用缩进表达树的层级，便于记录规则结构而不是只比较文本。
    fmt.Printf("%*sop=%s min=%d max=%d\n", depth*2, "", re.Op, re.Min, re.Max)

    // Sub 保存子表达式；递归只做结构观察，不改变节点内容。
    for _, child := range re.Sub {
        auditRegexp(child, depth+1)
    }
}

审计时可以记录 Op、Sub、Min、Max 等结构字段，再对比化简前后的节点变化。对于有捕获组的规则，还要保留捕获编号和调用方约定，不能因为结构更短就删除业务依赖。

把化简结果接到执行层之前

如果业务最终要匹配文本，可以把化简后的表示交给 regexp.Compile；但建议同时保存原始模式、解析模式、化简模式和错误信息。这样规则变更时，审计日志能够说明是输入变了，还是规范化过程变了。

func compileRule(raw string) (*regexp.Regexp, error) {
    // 先解析和化简，避免把未经整理的配置直接当作执行规则。
    parsed, err := syntax.Parse(raw, syntax.Perl)
    if err != nil {
        return nil, fmt.Errorf("parse rule: %w", err)
    }

    normalized := parsed.Simplify().String()
    // 编译的是规范表示；生产系统仍应把 raw 和 normalized 一起记入审计记录。
    compiled, err := regexp.Compile(normalized)
    if err != nil {
        return nil, fmt.Errorf("compile normalized rule %q: %w", normalized, err)
    }
    return compiled, nil
}

示例只展示接入边界，不代表 Simplify 自动完成安全过滤。正则来源如果可被外部修改，仍需限制长度、允许的语法和业务字段范围；化简完成后也应使用固定输入检查匹配结果，防止调用方误解捕获组或边界条件。

不要把 Simplify 当成性能承诺

化简后的树更容易阅读、比较和存档，并不等于所有输入都会在运行时更快。匹配性能还和模式形状、输入文本、编译结果以及调用频率有关。若要宣称收益，应另设基准：固定 Go 版本、固定模式集合、固定输入样本，分别测量解析、化简、编译和匹配阶段。

相关问题

Regexp.Simplify 会改变匹配语义吗？

它的目标是生成语义等价的简化表达式，但调用方仍应对捕获组、边界和量词写固定测试，不要只用字符串对比下结论。

为什么不直接用 regexp.Compile？

直接编译适合一次性规则；需要保留规则来源、查看结构或生成稳定规范表示时，先经过 regexp/syntax 更容易定位输入和语义变化。

把 Simplify 放在“解析与执行之间的规范化层”，同时保留原始规则和匹配用例，就能得到一条更清晰的 Go 正则处理链：输入可追溯、结构可解释、执行边界也不会被误写成性能或安全保证。