Go问答：regexp.Regexp LiteralPrefix正则查询怎样利用固定前缀减少扫描怎样完成一个可复用的最小示例

如果一批文本都要用同一个 Go 正则查询，先取出 regexp.Regexp.LiteralPrefix 返回的固定前缀，可以把明显不可能命中的文本挡在 MatchString 之前。关键是把它当作候选预筛选条件，最后仍交给正则匹配确认；没有固定前缀时则直接回退，不能为了“优化”改变原查询语义。

LiteralPrefix 返回的是匹配必经的字面量

LiteralPrefix 在已编译的 *regexp.Regexp 上调用，返回一个字符串和一个布尔值。字符串是“任意匹配都必须以它开头”的字面量；布尔值为 true 时，说明这个字面量已经覆盖整个正则表达式。它不是一次匹配的结果，也不代表正则只能在输入开头查找。

package main

import (
    "fmt"
    "regexp"
)

func main() {
    // 这个表达式的每个匹配都包含固定的 ERROR: 前缀。
    re := regexp.MustCompile(`ERROR:[0-9]+`)
    prefix, complete := re.LiteralPrefix()
    fmt.Printf("prefix=%q complete=%v\n", prefix, complete)

    // complete 只有在整个表达式都是字面量时才为 true。
    literal := regexp.MustCompile(`ERROR:`)
    literalPrefix, literalComplete := literal.LiteralPrefix()
    fmt.Printf("prefix=%q complete=%v\n", literalPrefix, literalComplete)
}

第一个表达式的固定部分是 ERROR:，后面的数字仍需要正则引擎判断。第二个表达式没有字符类或量词，完整性才可能为真。实际代码不要只检查 prefix 就返回命中，因为前缀相同并不等于后续部分符合正则。

先判断候选文本，再决定是否调用正则

前缀筛选最容易出错的地方是把“匹配内容以某个前缀开始”和“输入字符串以某个前缀开始”混为一谈。对于 ERROR:[0-9]+，匹配可以出现在一行中间，所以候选判断应使用 strings.Contains。如果表达式明确写成 ^ERROR:[0-9]+，匹配位置被限制在输入开头，才可以使用 strings.HasPrefix。

func mayContainPrefix(text, prefix string, anchored bool) bool {
    // 没有固定前缀时不能排除任何候选，交给正则表达式处理。
    if prefix == "" {
        return true
    }
    if anchored {
        // ^ 约束了匹配位置，输入也必须从 prefix 开始。
        return strings.HasPrefix(text, prefix)
    }
    // 非锚定表达式可能在文本中间命中，只能检查是否包含前缀。
    return strings.Contains(text, prefix)
}

上面的函数只做快速排除，不负责解释完整的正则语义。锚定信息要由调用方根据自己的查询契约传入，不要试图用简单的字符串查找去解析所有正则语法。

封装一个保留正则语义的最小查询函数

把编译、前缀提取、候选筛选和最终匹配放进一个函数，调用方只需要提供文本集合和正则表达式。下面的版本增加了 anchored 参数，并对完整字面量做了一个可读性更高的直接判断；它仍然保留 MatchString 作为最终保险。

package search

import (
    "regexp"
    "strings"
)

// FilterByRegexp 过滤文本；anchored 表示查询是否明确限制在输入开头。
func FilterByRegexp(lines []string, pattern string, anchored bool) ([]string, error) {
    re, err := regexp.Compile(pattern)
    if err != nil {
        // 把编译错误交给调用方，避免静默返回一个空结果集。
        return nil, err
    }

    prefix, complete := re.LiteralPrefix()
    matched := make([]string, 0, len(lines))
    for _, line := range lines {
        // 固定前缀为空时保留全部候选，避免错误丢弃合法匹配。
        if prefix != "" {
            hasPrefix := strings.Contains(line, prefix)
            if anchored {
                hasPrefix = strings.HasPrefix(line, prefix)
            }
            if !hasPrefix {
                continue
            }
        }

        // complete 只说明表达式是完整字面量，仍用统一匹配路径保证语义一致。
        _ = complete
        if re.MatchString(line) {
            matched = append(matched, line)
        }
    }
    return matched, nil
}

这个实现不会把前缀命中误报成最终结果，也不会因为正则无法提取前缀而返回错误的空列表。若你能严格保证 complete 为真，还可以针对纯字面量改用 strings.Contains 或 HasPrefix，但建议先保持统一路径，再用基准测试确认这项特化是否值得维护。

空前缀、大小写和收益不确定时怎么处理

前缀优化有明确边界。包含可变开头、交替分支没有共同字面量、大小写不敏感或表达式本身很短时，prefix 可能为空或筛选收益很小。此时跳过预筛选并不代表查询失败，而是避免引入一套容易误用的旁路逻辑。

最后要注意，LiteralPrefix 是语义信息，不是性能承诺。正则本身已经可能由实现做内部优化；你的外层预筛选还会增加一次字符串扫描。只有当文本集合大、前缀排除率高且正则确认成本明显时，才值得保留这层逻辑，并用真实数据比较总耗时。

常见问题

LiteralPrefix 返回的 prefix 能直接当成最终匹配结果吗？

不能。它只说明匹配必经的固定部分，后续字符、量词、字符类和边界仍需由 MatchString 判断。

为什么非锚定表达式不能统一使用 HasPrefix？

因为正则可能在输入中间命中。只有表达式明确使用 ^ 并且调用契约确实要求从字符串开头匹配时，HasPrefix 才不会误删候选。

前缀为空是不是 regexp 出错了？

不是。它表示实现无法从表达式提取可安全复用的固定开头，直接调用 MatchString 才是正确回退。