Go regexp.Regexp MarshalText 怎样保存和恢复正则

如果正则表达式来自配置文件、数据库或配置中心，通常不应该尝试保存 regexp.Regexp 的内部结构，而是保存它对应的文本。Go 的 regexp.Regexp 提供了 MarshalText 和 UnmarshalText，可以把“已编译对象”和“可迁移配置”分开处理：导出时拿到正则文本，启动时重新编译。

官方资料：https://pkg.go.dev/regexp#Regexp.MarshalText

最稳妥的做法是把正则放进字符串字段，恢复时显式处理错误。这样配置写错时可以返回清晰的启动错误，也不会因为 MustCompile 直接 panic。

把正则保存成可迁移的文本字段

MarshalText 实现的是 encoding.TextMarshaler。它返回的文本与 AppendText 追加出的内容一致，也对应 Regexp.String 的表达式文本。持久化层只需保存这个字符串，没必要保存编译后的状态。

package main

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

// StoredRule 只保存跨进程、跨版本更容易理解的正则文本。
type StoredRule struct {
	Pattern string `json:"pattern"`
}

func main() {
	// Compile 负责把配置中的表达式变成可匹配对象；这里不使用 MustCompile。
	re, err := regexp.Compile(`^go-[a-z]+-[0-9]+$`)
	if err != nil {
		fmt.Println("编译正则失败：", err)
		return
	}

	// MarshalText 导出的是正则表达式文本，适合写入 JSON 或配置中心。
	patternText, err := re.MarshalText()
	if err != nil {
		fmt.Println("导出正则文本失败：", err)
		return
	}

	data, err := json.Marshal(StoredRule{Pattern: string(patternText)})
	if err != nil {
		fmt.Println("编码配置失败：", err)
		return
	}
	fmt.Println(string(data))
}

这里的 JSON 只承载 pattern 字符串，生成的配置可以交给文件、数据库或配置中心。要注意，MarshalText 不是把 DFA、缓存或内部字段序列化出来；它保存的是重新编译所需的表达式文本。

启动时用 UnmarshalText 恢复匹配对象

恢复时可以声明一个零值 regexp.Regexp，再把配置字符串传给 UnmarshalText。官方实现会调用 Compile，因此返回的错误就是正则语法不合法或表达式无法编译时的错误。

package main

import (
	"fmt"
	"regexp"
)

// restoreRule 把配置文本恢复成可以并发使用的正则对象。
func restoreRule(text string) (*regexp.Regexp, error) {
	var re regexp.Regexp
	// UnmarshalText 内部按正则文本重新编译，失败必须交给启动流程处理。
	if err := re.UnmarshalText([]byte(text)); err != nil {
		return nil, fmt.Errorf("恢复正则 %q 失败: %w", text, err)
	}
	return &re, nil
}

func main() {
	re, err := restoreRule(`^go-[a-z]+-[0-9]+$`)
	if err != nil {
		fmt.Println(err)
		return
	}

	// 恢复完成后就按普通 Regexp 使用，配置文本不会影响匹配接口。
	fmt.Println(re.MatchString("go-http-200"))
}

如果恢复失败，应该让配置加载函数返回错误，或把服务留在不可用状态并输出脱敏后的配置标识。不要在生产启动路径里把错误吞掉后继续使用一个未初始化的规则。

恢复时要把文本错误和编译状态分开看

最容易忽略的是：文本只能表达正则本身，不能表达所有编译选项。比如通过 CompilePOSIX 得到的 POSIX 语义，以及调用 Longest 后的匹配选择，都不是普通表达式文本能完整标记的状态。

因此，普通配置可以直接用 UnmarshalText；如果规则还带有模式类型或匹配策略，建议把它们拆成独立字段，恢复文本后再按字段显式设置：

package main

import (
	"fmt"
	"regexp"
)

// RuleConfig 把表达式与不会自动包含在文本里的策略分开保存。
type RuleConfig struct {
	Pattern string
	Longest bool
}

func compileRule(cfg RuleConfig) (*regexp.Regexp, error) {
	// Compile 返回错误而不是 panic，适合处理外部配置。
	re, err := regexp.Compile(cfg.Pattern)
	if err != nil {
		return nil, err
	}
	if cfg.Longest {
		// Longest 是编译对象上的策略，恢复文本后需要显式重设。
		re.Longest()
	}
	return re, nil
}

func main() {
	re, err := compileRule(RuleConfig{Pattern: `a|ab`, Longest: true})
	if err != nil {
		fmt.Println("配置无效：", err)
		return
	}
	fmt.Println(re.FindString("ab"))
}

这里的 Longest 只是一个独立的恢复策略示例，不要把它误解成 MarshalText 会自动记住的内容。如果业务真的依赖 POSIX 语义，也应把模式类型显式写进配置，并在恢复时选择对应的编译入口。

几个容易踩到的边界

• 不要把文本当成编译缓存：它只保存表达式，启动或刷新配置时仍需要编译。
• 不要用 MustCompile 处理外部配置：格式错误应变成可追踪的返回错误，而不是进程 panic。
• 不要忽略策略字段：Longest、POSIX 等语义要和 pattern 一起设计，不能只保存一个字符串。
• 不要把错误原文当作敏感信息：日志可以记录配置版本、字段名和错误类型，避免直接输出可能包含业务规则的完整表达式。

常见问题

MarshalText 和 String 有什么区别？

它们都围绕正则表达式文本工作；MarshalText 以 []byte, error 形式实现文本编解码接口，更适合接入显式的序列化流程，而 String 直接返回字符串。

UnmarshalText 失败后还能继续使用原对象吗？

不要依赖失败后的对象状态。把恢复放在临时变量中，成功后再替换线上规则，失败则保留旧规则或拒绝这次配置更新。

总结一下：把正则保存为文本，把 MarshalText 当作导出入口，把 UnmarshalText 或 Compile 当作恢复入口，再把 Longest、POSIX 等额外语义作为独立配置恢复。这样既能保持配置可读，也能让错误处理和规则切换边界清楚。