正则匹配

Go 的 regexp.Compile 成功，只说明模式语法能够解析，不代表当前输入一定命中。re.MatchString(input) 返回的是 bool，不会返回空字符串；如果日志显示“结果为空”，应先确认是不是读取了 FindString 的结果，或者在业务封装里把 false 转成了空值。

我会先将问题拆成模式、输入、接口返回值三件事，再动正则本身。否则很容易为了让样本“通过”而删除必要的约束，最后把错误输入也放进业务系统。

官方文档：https://pkg.go.dev/regexp

先确定日志里的空值来自哪个接口

如果调用的是编译后对象的方法，记录 matched=false 比“正则结果为空”更明确。配置错误则保留为 error，不能把编译失败也归入普通的不匹配。这是我更愿意保留的区分：配置有问题与业务输入不符合规则，需要不同处理。

把模式和输入的真实内容保留下来

眼睛看见的 AB-204，实际可能是带换行的字符串。下面用一个编号规则展示诊断方法；这段代码是读者可自行运行的原创样例，本文不把它描述为已执行结果。

package main

import (
    "fmt"
    "regexp"
)

func main() {
    pattern := `\A[A-Z]{2}-[0-9]{3}\z`
    input := "AB-204\n" // 故意保留换行，展示肉眼不可见的输入差异。
    re, err := regexp.Compile(pattern)
    if err != nil {
        fmt.Printf("正则编译失败: %v\n", err)
        return // 配置错误不能当作普通业务不匹配。
    }
    // 此处只有人为构造的样本；真实业务不要直接打印敏感内容。
    fmt.Printf("pattern=%q input=%q bytes=%d\n", re.String(), input, len(input))
    matched := re.MatchString(input)
    index := re.FindStringIndex(input)
    fmt.Printf("matched=%t index=%v\n", matched, index)
}

这个模式限定两个大写英文字母、连接符和三位数字，并限制整串范围。样例末尾的换行不属于编号，所以按规则应不匹配。应先确认数据协议：如果换行是传输分隔符，就在对应读取层移除它；如果编号字段本来不允许换行，就拒绝输入。不要无条件 TrimSpace 来掩盖上游问题。

还要区分 Go 字符串和正则转义两层语义。反引号原始字符串 `\d+` 与双引号字符串 "\\d+" 才能把相同的正则反斜杠传进去。若模式来自 JSON 配置，还应看解码后的字符串，而不是只看配置文件的展示形式。

区分没有命中和零长度命中

FindString 返回空字符串时，可能完全没有命中，也可能确实命中了一个零长度区间。我更倾向于在诊断中用位置接口把两者拆开，避免在业务封装里丢失信息。

// 片段放在 main 内，沿用前例的 fmt 和 regexp 导入。
re, err := regexp.Compile(`[0-9]*`)
if err != nil {
    fmt.Printf("正则编译失败: %v\n", err)
    return
}
input := "word"
loc := re.FindStringIndex(input)
switch {
case loc == nil:
    fmt.Println("没有匹配")
case loc[0] == loc[1]:
    // 位置存在但区间长度为零，不能误报成没有匹配。
    fmt.Printf("零长度匹配，字节位置=%d\n", loc[0])
default:
    fmt.Printf("匹配文本=%q\n", input[loc[0]:loc[1]])
}

这里 [0-9]* 允许零个数字，因此 word 开头可以出现零长度命中；这并不是 Compile 的故障。如果业务要求至少一位数字，应根据需求使用 [0-9]+，并进一步决定是否需要整串约束。索引值是字节偏移，处理中文时不能直接当作字符数量。

给业务规则限定整串匹配范围

MatchString 默认询问的是输入中是否有一段匹配，不是整个字段是否符合规则。对于格式校验，我会显式限定整串；对于日志内容搜索，则通常保留局部查找语义。这两类需求不能混成一个布尔值约定。

Go 的正则语法中，\A 和 \z 固定表示文本起止位置。^、$ 会受到多行模式 (?m) 影响；. 默认不覆盖换行，(?s) 才改变这一点。字符类、大小写和换行规则都应对应业务需求，不要用一个 .* 扩大所有匹配。

官方语法说明：https://pkg.go.dev/regexp/syntax。例如业务只接受 ASCII 数字时，[0-9] 能直接表达这个限制；不要因为视觉上像数字就默认所有字符都属于相同集合。

在服务中记录足够的信息

在生产服务中，我会保留规则标识、编译状态、输入字节长度、matched 和经过批准的诊断信息。样例里的 %q 适合人工构造数据或获准的排障环境；真实输入可能含口令、身份信息或业务正文，不应直接写入普通日志。

正则配置更新时先编译新规则，失败就报告配置错误；不要在失败后偷偷使用空模式。开发者固定的表达式可以在初始化时编译并复用，而外部配置更适合显式处理 Compile 返回的错误。

接入前至少列出：正确编号、带尾部换行、错误大小写、空输入、只含局部编号的文本五类样本。每项写清业务期望，分别断言编译与匹配，不要只判断 FindString 的长度。我认为这个做法更适合字段校验和接口过滤；如果只是临时搜索一段文本，不必引入完整的规则配置体系。

几个常见疑问

Compile 没报错，为什么仍然是 false？

合法模式与当前输入未必匹配。应检查真实输入、转义、字符集合和起止位置限制。

FindString 为空，MatchString 却为 true，矛盾吗？

不矛盾。模式可能允许零长度命中，用 FindStringIndex 查看是否存在长度为零的位置区间。

删掉锚点后命中了，能直接上线吗？

要看业务是否接受局部命中。字段校验通常不应因为局部片段合法，就接受整段不合法输入。