Go regexp.Regexp.MarshalText 怎么保存正则配置：编译恢复与错误边界

把正则表达式放进 JSON、YAML 或配置中心时，真正需要保存的是模式文本，而不是 *regexp.Regexp 的内部状态。Go 的 regexp.Regexp.MarshalText 会输出 Regexp.String() 对应的文本，读取配置时 UnmarshalText 再调用 Compile；模式非法，错误会原样留在恢复阶段。

适合保存“可重新编译的正则模式”，不适合把编译结果当成完整快照；如果使用过 CompilePOSIX 或 Longest，还要额外保存模式语义。

为什么配置文件应该保存正则文本

regexp.Regexp 实现了文本编解码接口，因此它可以直接作为结构体字段参与编码。示例里的 Rule.Pattern 是可读配置，json.Marshal 负责调用 MarshalText，输出值仍然是 ^go-[0-9]+$ 这样的模式。

package main

import (
    "encoding/json"
    "fmt"
    "regexp"
)

type Rule struct {
    Name    string         `json:"name"`
    Pattern *regexp.Regexp `json:"pattern"`
}

func main() {
    rule := Rule{
        Name:    "release-tag",
        Pattern: regexp.MustCompile(`^go-[0-9]+$`),
    }
    data, err := json.Marshal(rule)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(data))
}

这条调用链是 json.Marshal → Regexp.MarshalText → Regexp.AppendText。保存下来的只是稳定的文本，所以配置文件可以被人工检查，也不会依赖某个 Go 进程里的内部编译状态。

恢复时为什么一定要检查 UnmarshalText 的错误

读取配置时，encoding/json 会把字符串交给 Regexp.UnmarshalText。该方法先执行 Compile，只有编译成功才把新对象赋给目标；因此非法文本不会悄悄覆盖旧规则。

func loadRule(data []byte, current *regexp.Regexp) error {
    var candidate regexp.Regexp
    if err := json.Unmarshal(data, &candidate); err != nil {
        return err
    }
    *current = candidate
    return nil
}

这里的真实状态变化是：配置文本进入 UnmarshalText，再到 Compile；编译失败走 error 分支，成功才替换 current。生产配置热更新时，使用临时变量比直接修改共享规则更容易回滚。

MarshalText 能不能完整保存所有匹配语义

不能把它当成完整快照。官方源码说明，MarshalText 的输出与 Regexp.String 一致；而 AppendText 明确提醒，这个输出在某些场景有损：它不会标记正则是由 CompilePOSIX 编译的，也不会表达是否调用过 Longest。

普通模式的往返可以这样验收：

func roundTrip(pattern string) error {
    original, err := regexp.Compile(pattern)
    if err != nil {
        return err
    }

    text, err := original.MarshalText()
    if err != nil {
        return err
    }

    var restored regexp.Regexp
    if err := restored.UnmarshalText(text); err != nil {
        return err
    }
    if restored.String() != original.String() {
        return fmt.Errorf("pattern changed: %q -> %q", original.String(), restored.String())
    }
    return nil
}

如果业务依赖 POSIX 语义或最长左匹配，应把 posix、longest 作为独立配置字段保存，加载时先读取这些字段，再选择 Compile 或 CompilePOSIX，并在需要时调用 Longest。不要指望一段纯文本自动记住这些额外开关。

配置热更新时的三个检查点

• 先校验 JSON 字段和正则文本，保留旧规则直到候选规则编译成功。
• 把 regexp.Compile 返回的 *syntax.Error 记录到配置版本日志，便于定位具体模式。
• 如果保存了 CompilePOSIX 或 Longest 语义，配置中显式记录开关，并为两种匹配结果写测试。

相关问题

MarshalText 会保存 regexp.Regexp 的内部指令吗？

不会。它输出可重新编译的模式文本，内部程序结构不会进入配置。

UnmarshalText 遇到非法正则会清空原对象吗？

源码先编译到 newRE，成功后才赋值；调用方仍应通过临时变量保护当前线上规则。

JSON 里能直接写 regexp.Regexp 字段吗？

可以写字符串字段，JSON 编解码会使用文本编解码接口；但必须检查 json.Unmarshal 的错误。

为什么恢复后匹配结果和原来不一样？

优先检查是否使用了 CompilePOSIX 或 Longest，这些语义不会由普通模式文本完整表达。

小结

MarshalText 和 UnmarshalText 的价值在于把正则配置变成可读、可审核、可重新编译的文本协议。普通 Compile 模式可以稳定往返；带有 POSIX 或最长匹配语义时，则要把额外开关一并建模，加载失败时保留旧规则。