Go regexp/syntax.Parse 怎样把正则模式转成可分析语法树

如果只需要判断一段文本是否匹配正则，通常调用 regexp.Compile 和 MatchString 就够了；但做规则检查器、配置审查器或开发辅助工具时，往往还要知道模式由哪些操作组成。这时可以使用 regexp/syntax：调用 syntax.Parse 把字符串模式解析成 *syntax.Regexp，再递归读取节点的操作类型和子表达式。

官方文档地址：https://pkg.go.dev/regexp/syntax#Parse

syntax.Parse 的结果是一棵正则语法树。根节点和子节点通过 Op、Sub、Rune、Min、Max、Name 等字段描述结构；解析失败时先处理 error，不要把错误模式继续交给匹配阶段。

调用 syntax.Parse 得到语法树

syntax.Parse 接收正则字符串和解析标志，成功时返回语法树根节点，失败时返回错误。常见的 syntax.Perl 标志组合更接近 regexp 包使用的 Perl 风格语法；如果工具只接受 POSIX 语法，则可以传入 syntax.POSIX。解析标志要和业务允许的表达式范围保持一致。

package main

import (
    "fmt"
    "regexp/syntax"
)

func parsePattern(raw string) (*syntax.Regexp, error) {
    // 使用 Perl 标志解析常见的字符类、分组和重复表达式。
    tree, err := syntax.Parse(raw, syntax.Perl)
    if err != nil {
        // 解析失败时保留原始错误，调用方可以显示具体表达式问题。
        return nil, fmt.Errorf("正则模式解析失败: %w", err)
    }
    return tree, nil
}

这里得到的 tree 只是可分析的语法树，并不等同于已经完成匹配的对象。工具可以先用它做规则审查、统计或格式化；需要真正匹配文本时，再把同一模式交给 regexp.Compile，让职责保持清晰。

先读取根节点的 Op，再处理 Sub

syntax.Regexp.Op 表示当前节点的操作类型。串联表达式通常对应 OpConcat，选择对应 OpAlternate，重复对应 OpStar、OpPlus、OpQuest 或 OpRepeat，字面量则常见为 OpLiteral。组合节点的细节放在 Sub 切片中，因此不要只打印根节点的 String() 就结束。

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

    // 缩进只用于让摘要体现树形层级，不改变语法树本身。
    fmt.Printf("%*sOp=%s", depth*2, "", node.Op)
    if node.Name != "" {
        fmt.Printf(" Name=%q", node.Name)
    }
    fmt.Println()

    // Sub 保存当前组合节点的子表达式，递归后才能看到完整结构。
    for _, child := range node.Sub {
        walkRegexp(child, depth+1)
    }
}

递归函数只负责展示结构，实际工具可以把每个节点转换成自己的摘要对象。关键是用 Op 决定读取哪些字段：字面量节点关心 Rune，重复节点关心 Min 和 Max，组合节点关心 Sub。

按节点类型读取 Rune、Min、Max 与 Name

Regexp 节点的字段不是每一种操作都会使用。把所有字段无条件拼成一行，容易让阅读者误以为零值也有业务含义。可以按操作类型生成摘要：OpLiteral 使用 Rune 表示匹配的字符序列，OpCharClass 使用成对的范围数据，OpRepeat 使用 Min 与 Max，捕获节点再补充 Name 和 Cap。

type NodeSummary struct {
    Op       string
    Text     string
    Min, Max int
    Name     string
    Children []NodeSummary
}

func summarize(node *syntax.Regexp) NodeSummary {
    // 先记录所有节点都有的操作名，再按操作读取专属字段。
    result := NodeSummary{Op: node.Op.String()}
    switch node.Op {
    case syntax.OpLiteral, syntax.OpCharClass:
        // Rune 对字面量和字符类最有解释价值，其他节点通常为空。
        result.Text = string(node.Rune)
    case syntax.OpRepeat:
        // Max 为 -1 表示没有上限，不能把它误写成普通负数次数。
        result.Min, result.Max = node.Min, node.Max
    case syntax.OpCapture:
        // Name 为空时仍可能是编号捕获组，不能只保留有名字的组。
        result.Name = node.Name
    }

    // 子节点递归摘要后，调用方可以序列化为 JSON 或树形文本。
    for _, child := range node.Sub {
        result.Children = append(result.Children, summarize(child))
    }
    return result
}

如果目标是做规则比较，可以使用 Regexp.Equal 比较两棵树的结构；如果目标是减少重复，才考虑 Simplify。简化可能重写重复表达式，甚至影响捕获括号的树形结构，所以“原始结构审查”和“执行前简化”最好使用不同的变量。

处理解析错误，再进入匹配阶段

解析失败是模式输入的问题，常见原因包括括号或字符类没有闭合、转义不合法、重复次数超出限制等。regexp/syntax.Error 会带有错误代码和相关表达式，调用方可以把它包装上配置项名称后返回。模式解析成功后，文本没有匹配到则属于正常业务结果，不能再回头查解析错误。

func inspectAndCompile(raw string) (*syntax.Regexp, error) {
    tree, err := syntax.Parse(raw, syntax.Perl)
    if err != nil {
        // 解析阶段失败就立即返回，避免后续代码使用空树。
        return nil, err
    }

    // 只在结构检查通过后继续做工具需要的摘要或编译准备。
    return tree, nil
}

实际服务可以在配置加载或热更新阶段完成这一步，运行请求只读取已经通过检查的规则。这样既能把用户输入错误尽早反馈，也能避免每个请求重复解析同一条模式。

小结：把语法树当成分析输入

常见问题：

• syntax.Parse 和 regexp.Compile 有什么区别？ 前者返回可分析的语法树，后者返回面向匹配的正则对象；前者适合规则检查和工具化处理。
• 为什么只看 Regexp.String 不够？ 字符串表示适合展示，不能替代对 Op、Sub 和重复边界的结构化读取。
• 什么时候调用 Simplify？ 只有在你明确需要执行前的等价简化时调用；要保留用户原始结构时应分析 Parse 的原树。