Go regexp 怎么预编译并复用在高频日志过滤中

高频日志过滤时，正则表达式不要跟着每条日志重新编译。把 regexp.Compile 放在初始化或规则加载阶段，保存返回的 *regexp.Regexp，热路径只调用 MatchString 等匹配方法。这样既能把非法规则尽早暴露，也能让多个 goroutine 安全复用同一个已编译对象；需要改规则时，创建新过滤器并整体替换，不要在匹配期间修改旧对象的配置。

固定规则用 MustCompile 或启动阶段的 Compile，高频请求只做匹配；Regexp 可以并发使用，但 Longest 这类配置方法不应和并发匹配混用。

先把编译和匹配拆开

regexp.Compile 会解析表达式并返回已编译的 *Regexp；表达式不合法时返回 error。regexp.MatchString 适合简单的一次性调用，但同一表达式在高频日志中反复使用时，应保存 *Regexp，避免把规则准备动作放回每条日志的热路径。固定规则可以用 MustCompile 在包初始化时建立，配置来自文件或环境变量时则应使用 Compile，把错误交给启动流程。

用一个过滤器集中保存已编译规则

下面的小项目只保留一条规则，真实服务可以把它扩展成多条规则切片。过滤器构造函数负责编译，Match 只接收日志文本；职责拆开后，调用方不会不小心把编译动作放回循环。

package main

import (
	"fmt"
	"regexp"
)

type LogFilter struct {
	pattern string
	re      *regexp.Regexp
}

func NewLogFilter(pattern string) (*LogFilter, error) {
	// 配置加载阶段编译，非法表达式直接返回给启动流程。
	re, err := regexp.Compile(pattern)
	if err != nil {
		return nil, fmt.Errorf("compile log filter %q: %w", pattern, err)
	}
	return &LogFilter{pattern: pattern, re: re}, nil
}

func (f *LogFilter) Match(line string) bool {
	// 热路径只做匹配，不重新解析 pattern。
	return f.re.MatchString(line)
}

func main() {
	filter, err := NewLogFilter(`level=(ERROR|WARN)`)
	if err != nil {
		panic(err) // 示例程序让配置错误立即可见。
	}
	for _, line := range []string{"level=INFO ready", "level=ERROR disk full"} {
		fmt.Println(filter.Match(line), line)
	}
}

这里的 pattern 只是保留原始配置，便于日志或规则展示；真正参与匹配的是 re。如果规则来自远程配置，加载失败时应保留旧过滤器并记录错误，避免把一个 nil 匹配器发布给请求处理协程。

并发复用时哪些状态不能共享

Go 官方文档明确说明，Regexp 除配置方法外可以被多个 goroutine 并发使用。因此多个 worker 共享一个只读过滤器是合理的：每个 worker 提供自己的日志字符串，调用同一对象的 MatchString。不要为了“线程安全”给每个日志创建一个正则，也不必再用已废弃的 Copy 解决旧版本的锁竞争问题。

如果业务支持在线改规则，推荐把规则加载写成“编译新对象、检查成功、替换过滤器引用”。替换动作需要由你的配置管理层保证原子性，例如用 atomic.Value 保存完整的 *LogFilter；不要在旧 Regexp 上调用 Longest，同时让其他协程继续匹配。

type FilterStore struct {
	current atomic.Value // 存放完整的 *LogFilter，读者只取当前快照。
}

func (s *FilterStore) Load() *LogFilter {
	return s.current.Load().(*LogFilter)
}

func (s *FilterStore) Replace(pattern string) error {
	// 先编译新规则，失败时不影响正在服务的旧规则。
	next, err := NewLogFilter(pattern)
	if err != nil {
		return err
	}
	s.current.Store(next) // 整体替换，避免修改共享对象内部状态。
	return nil
}

这段片段需要额外导入 sync/atomic，并在首次 Load 前先 Store 一个初始过滤器。它展示的是配置边界，不是完整配置中心；若规则永远不变，直接把 *LogFilter 作为服务依赖注入更简单。

常见问题

每次调用 regexp.MatchString 都一定很慢吗？

不应把它简单理解成“一定很慢”，但在同一表达式被高频重复使用时，显式保存 *Regexp 能避免反复编译，边界更清楚。是否值得优化仍应结合真实日志量测量。

多个 goroutine 能直接调用同一个 Regexp 吗？

可以。匹配方法属于安全的并发使用范围；共享的是已编译规则，日志字符串和返回结果仍由每次调用各自提供。

规则变更时能直接修改原来的 Regexp 吗？

不要把匹配中的对象当作可变配置容器。先用新表达式编译新对象，成功后替换完整过滤器；如果要改变 Longest 等配置，也应让新对象承担这份配置。

什么时候应该用 MustCompile？

只有表达式是源码固定值、写错就应该让程序初始化失败时才适合。外部配置、用户输入和远程下发规则使用 Compile，让调用方决定回滚或拒绝策略。