Go x/text/search 语言搜索为什么可能匹配不同长度文本

我第一次把 golang.org/x/text/search 放进多语言检索代码时，最容易误判的一点是：查询词和命中文本的原始长度不一定相同。这个包不是把字符串逐字节比较，也不是简单把每个 rune 映射成一个固定字符，而是按语言标签生成可比较的排序元素，再把匹配结果映射回原始文本。

官方地址：https://pkg.go.dev/golang.org/x/text/search

出现不同长度匹配通常不是索引错了，而是语言搜索允许多个原始字符或变体落到相近的比较权重。IndexString 返回的 start 和 end 仍然服务于原字符串切片，所以要按原文边界使用它们，不能把它们当成匹配权重数量。

它比较的是语言规则，不是字节相等

search.New 接收 language.Tag 和若干 Option，返回一个按语言工作的 Matcher。官方文档用丹麦语的“Århus”和“Aarhus”、土耳其语的大小写关系说明了这个包要处理的语言特例；输入文本也不要求事先标准化。

因此，搜索过程可以抽象成三层：原始字符串、语言相关的排序元素、原文中的命中区间。排序元素用于比较，命中区间却必须回到输入字符串的位置。只要把这两层混在一起，就会把“不同长度”误认为库返回了错误下标。

哪些选项会扩大可匹配范围

默认行为按字符级别匹配。IgnoreCase 忽略大小写，IgnoreDiacritics 忽略重音符号，IgnoreWidth 把窄体和宽体视作相等；Loose 会同时打开这三类忽略规则。它们改变的是比较规则，不会改写原字符串。

如果业务需要“显示上相近就算命中”，可以选择对应的忽略选项；如果业务是协议字段、唯一键或签名材料，就不应该默认使用宽松匹配。Exact 要求两个字符串是精确等价，并且会覆盖忽略类选项。例如官方文档明确指出，在丹麦语规则下，å 不会在 Exact 下匹配 aa。

package main

import (
    "fmt"

    "golang.org/x/text/language"
    "golang.org/x/text/search"
)

func main() {
    // 忽略重音后，查询词可以命中带重音的原文片段。
    relaxed := search.New(language.English, search.IgnoreDiacritics)
    start, end := relaxed.IndexString("café latte", "cafe")
    fmt.Println(start, end)

    // Exact 收紧比较规则，适合不允许语义放宽的字段。
    exact := search.New(language.Danish, search.Exact)
    exactStart, exactEnd := exact.IndexString("Aarhus", "å")
    fmt.Println(exactStart, exactEnd)
}

上面的返回值应按“原文区间”理解，而不是按排序元素个数理解。第一组命中包含原文里的重音字符时，end-start 可以和查询词的字节长度不同；第二组在精确规则下可能返回 -1, -1，表示没有命中。

IndexString 的下标要按原字符串处理

Matcher.IndexString 和 Pattern.IndexString 返回首次命中的 start、end；未命中时返回 -1, -1。工程上最重要的约束是：这两个值用于切分传入的原字符串，所以不要先把字符串转成 rune 切片，再把返回值当作 rune 下标。

func highlight(m *search.Matcher, text, query string) string {
    // start 和 end 对应 text 的原始切片边界，未命中时不能切片。
    start, end := m.IndexString(text, query)
    if start 

这里的方括号只是展示用途。真正的 HTML 高亮还要做转义，并根据业务决定是否允许重音、大小写或宽度差异被显示为同一个命中。不要用 len([]rune(text)) 去校正 end，那会把字节区间和 rune 数量混在一起。

WholeWord 和 Anchor 解决的是另一类边界

WholeWord 约束完整单词，默认则是字符级匹配；它与忽略大小写、重音或宽度不是同一维度。一个查询即使在语言比较层相等，也可能因为不构成完整单词而不应作为词命中。

Anchor 是 Index 方法的 IndexOption，用于把搜索限制在文本开头；文档还定义了 Backwards，但当前包的源码实现对反向搜索仍保留未完成路径，因此不要把它当作可移植的“从末尾查找”方案。

func startsWithWholeWord(m *search.Matcher, text, query string) bool {
    // Anchor 只限制起点；WholeWord 决定匹配是否必须覆盖完整单词。
    start, end := m.IndexString(text, query, search.Anchor)
    if start != 0 || end  start
}

如果要做真正的词边界判断，还需要结合产品自己的分词规则，因为“完整单词”并不等同于所有语言的自然语言词法。WholeWord 是匹配选项，不是完整分词器。

固定查询可以编译成可复用 Pattern

当同一个查询要检查很多文本时，可以先调用 CompileString 得到 Pattern。官方文档说明，Pattern 是编译后的搜索字符串，并且可以安全地并发使用；这解决的是查询准备工作复用，不代表不同语言的规则可以混用。

func findInTexts(tag language.Tag, query string, texts []string) []string {
    // Matcher 决定语言规则，Pattern 只保存这个 Matcher 下的编译查询。
    matcher := search.New(tag, search.IgnoreCase)
    pattern := matcher.CompileString(query)
    hits := make([]string, 0, len(texts))

    for _, text := range texts {
        // 读取 Pattern 不改变它，适合在多个请求中复用同一个查询。
        start, end := pattern.IndexString(text)
        if start >= 0 && end >= 0 {
            hits = append(hits, text[start:end])
        }
    }
    return hits
}

如果查询规则需要变化，应重新创建带有正确语言标签和选项的 Matcher 与 Pattern。不要为了复用而把一个英语规则的 Pattern 当作所有语言的通用匹配器。

我会怎样排查“长度不一样”的结果

1. 先记录输入字符串、查询词、语言标签和选项，确认是否打开了 Loose、IgnoreDiacritics 或 IgnoreWidth。
2. 再打印 start、end 和原文切片，确认下标是否直接用于原字符串，而不是用于 rune 数组。
3. 如果业务要求逐字符或逐字节一致，改用 Exact，并重新定义“完整单词”是否应该由 WholeWord 负责。
4. 固定查询量较大时再引入 Pattern 复用，先把语言和匹配选项固定下来。

结语

Go x/text/search 允许不同原始长度的文本匹配，是语言排序模型带来的正常结果：比较层可以折叠大小写、重音、宽度或语言特例，但结果区间仍然属于原文。把 Matcher 的语言规则、Pattern 的复用边界和 IndexString 的原文下标分开理解，问题就不会再被“字符串长度不同”带偏。

相关问题

• 为什么不先用 strings.ToLower？ 语言相关大小写并不总能用简单的小写转换表达，search 的规则还涉及重音、宽度和语言特例。
• Pattern 能跨语言复用吗？ 不建议。Pattern 绑定创建它的 Matcher，而 Matcher 又绑定语言标签和选项。
• 未命中时怎样避免切片越界？ 先判断 start ，再使用原字符串切片。