Go regexp.ReplaceAllStringFunc 如何避免回调修改共享状态

Go 的 regexp.ReplaceAllStringFunc 适合“匹配到什么，就按内容计算出什么”的动态替换。真正容易出问题的不是正则本身，而是回调把计数器、map、切片或复用缓冲区放到了多个请求之间：一次调用还看不出异常，多个 goroutine 同时处理文本时就可能出现数据竞争或结果串线。

最稳妥的写法是让回调只读取不可变配置，并根据当前匹配返回新字符串；需要统计时把状态放在一次替换调用的局部作用域，必须跨调用共享的数据再单独用锁或汇总机制管理。

先看清 ReplaceAllStringFunc 交给回调什么

官方定义是：它复制输入字符串，把每个匹配替换为回调应用于匹配子串后的返回值；返回值按字面内容使用，不走 Regexp.Expand。因此回调签名只有 func(string) string，参数 matched 是完整匹配，不是某个捕获组。

例如给配置文本中的环境变量加上统一前缀，可以把规则和状态分开：

package main

import (
    "fmt"
    "regexp"
)

func main() {
    re := regexp.MustCompile(`\$\{([A-Z_]+)\}`)
    prefix := "cfg_" // 规则只读，回调不修改它。
    input := "host=${DB_HOST}, port=${DB_PORT}"

    output := re.ReplaceAllStringFunc(input, func(matched string) string {
        // 这里只根据当前完整匹配生成结果，不写共享切片或 map。
        return prefix + matched[2:len(matched)-1]
    })
    fmt.Println(output)
}

这段代码的结果是 host=cfg_DB_HOST, port=cfg_DB_PORT。如果替换文本本身包含美元符号，也不会被当成展开模板；这正是它与 ReplaceAllString 的一个重要区别。

把计数和去重状态限制在一次替换里

共享状态通常来自一个看似方便的闭包：回调里累加 count，或把已经见过的匹配写入包级 map。只要这个函数可能被多个请求同时调用，状态就不再属于某一份输入。

更好的方式是让外层函数拥有本次调用的状态。回调仍然可以修改这个局部变量，但它不会被下一次调用复用：

func redactRepeated(input string, re *regexp.Regexp) (string, int) {
    seen := make(map[string]struct{}) // 每次调用独立创建，避免请求之间串数据。
    repeated := 0

    output := re.ReplaceAllStringFunc(input, func(matched string) string {
        // map 只服务于当前输入；回调返回新文本，不把匹配保存给外部使用。
        if _, exists := seen[matched]; exists {
            repeated++
            return ""
        }
        seen[matched] = struct{}{}
        return ""
    })
    return output, repeated
}

调用者拿到的是“结果 + 本次统计”，而不是从全局变量里猜这次请求处理了多少项。若输入中有相同匹配，这种统计也只在当前字符串内生效。不要把 seen 提升到包级来节省一次分配；那会把生命周期、清理和并发安全问题一起带进业务层。

并发时，安全的是 Regexp，不是你的闭包

*regexp.Regexp 官方文档明确说明可供多个 goroutine 并发使用（配置类方法除外）。这句话只覆盖正则对象本身，不覆盖回调捕获的 map、切片、计数器或可变缓冲区。

如果业务必须记录跨请求的命中数，可以把锁只放在共享统计的临界区；如果只是为了得到总数，优先让每个调用返回局部值，最后在调用方汇总：

type Counter struct {
    mu    sync.Mutex
    total int
}

func replaceAndCount(input string, re *regexp.Regexp, counter *Counter) string {
    return re.ReplaceAllStringFunc(input, func(matched string) string {
        counter.mu.Lock() // 只保护共享计数，不把整个替换过程锁住。
        counter.total++
        counter.mu.Unlock()
        return "[MASKED]"
    })
}

上面示例需要补充 sync 导入。锁能避免数据竞争，却不会让多个请求拥有可预测的全局顺序；如果统计必须按输入顺序写入日志，应该让 worker 返回记录，交给单独的汇总阶段排序。还有一点容易忽略：不要让回调把 matched 的地址、复用的临时缓冲区或外部可变字符串长期保存，返回值应当代表这次替换的独立结果。

捕获组、API 选择和排查清单

如果需求是“按第一个捕获组替换”，不要以为回调参数会自动变成组内容。可以在回调里对当前匹配再次调用 FindStringSubmatch，也可以先用 FindAllStringSubmatchIndex 得到索引后自己组装结果。单纯的固定替换则用 ReplaceAllString；它的模板才支持 $1 一类展开语义。

最后用重复输入、空匹配、无匹配和并发调用覆盖测试，并执行 go test -race ./...。竞态检测只能帮助确认访问冲突，不能替你决定“统计是否应该共享”；这个决定要回到业务语义。

相关问题

ReplaceAllStringFunc 会按什么范围替换？

它处理正则找到的全部非重叠匹配；相邻空匹配有 regexp 包统一的匹配规则，不应在回调里自行假设字符下标连续。

只读的全局正则需要加锁吗？

通常不需要。可并发使用的是已编译的 Regexp；真正需要审查的是回调捕获的外部可变状态。

加 mutex 后是否一定能得到稳定顺序？

不能。mutex 解决并发访问冲突，不保证请求完成顺序；需要顺序时应在调用方收集局部结果后统一排序或串行写出。