Go x/text/search IgnoreCase 为什么不同于先转小写

我第一次把多语言名称搜索接进 Go 小工具时，直觉方案是对关键词和原文都调用 strings.ToLower。英文测试很顺，换成土耳其语后，结果却开始和用户理解不一致。这个问题的关键不是“再多转几次小写”，而是IgnoreCase 保留输入文本，并把大小写不敏感交给带语言规则的 Matcher 处理。

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

项目目标：先把问题缩小到语言感知搜索

为了避免把 API 讲成抽象概念，我做了一个很小的命令行搜索工具：输入一段原始文本、一个语言标签和一个关键词，输出是否相等以及关键词第一次出现的区间。这个项目不负责分词，也不负责把 Unicode 文本“清洗成 ASCII”，只回答一个问题：在指定语言规则下，两个字符串是否应当视为同一个搜索目标。

官方文档把 search 描述为语言相关的搜索与字符串匹配包。它举出的典型边界是：土耳其语的大小写匹配不能简单套用英语直觉，丹麦语中的名称匹配也可能涉及语言相关等价关系。也就是说，大小写不是一张全球通用的 ASCII 映射表。

环境准备：只引入搜索和语言两个包

新建一个目录，并初始化 module。示例使用当前官方文档中的导入路径；依赖版本由项目自己的 go.mod 决定，不把某个版本号硬编码成文章结论。

mkdir case-search-demo
cd case-search-demo
go mod init example.com/case-search-demo
go get golang.org/x/text/search golang.org/x/text/language
# 先让 Go modules 记录依赖，后续代码只围绕 IgnoreCase 做实验

这里没有先把输入变成小写。原因很实际：如果原文之后还要展示给用户、写回索引或记录审计日志，预处理后的字符串已经不是用户提交的原文了。匹配层单独持有选项，比较容易把“显示值”和“比较规则”分开。

核心代码：把 Matcher 放进一个小工具

search.New 接收一个 language.Tag 和若干选项，返回 *Matcher。这个 Matcher 既能做两个字符串的等价判断，也能返回关键词在原文中的起止位置。下面的代码选择土耳其语，是为了让“大小写规则跟语言有关”变得可观察；它没有修改 text 和 query。

package main

import (
	"fmt"

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

func main() {
	text := "Istanbul"
	query := "ıstanbul"

	// 语言标签决定匹配规则；IgnoreCase 只声明大小写不敏感。
	matcher := search.New(language.Turkish, search.IgnoreCase)

	// EqualString 比较语言相关等价性，不会改写 text 或 query。
	equal := matcher.EqualString(text, query)

	// IndexString 返回字节切片中的起止位置；找不到时返回 -1, -1。
	start, end := matcher.IndexString(text, query)

	fmt.Printf("equal=%v start=%d end=%d\\n", equal, start, end)
}

这段代码里最容易被忽略的参数是 language.Turkish。如果把语言标签换成一个泛化标签，程序仍然能运行，但匹配语义就不再是“按土耳其语规则判断”。所以我会把语言标签当作业务输入的一部分，而不是在工具内部偷偷写死。

本地运行：先看结果位置，再看字符串内容

运行程序时，我会同时记录 equal、start 和 end。EqualString 适合做过滤条件，IndexString 适合把命中范围交给高亮或摘要层。官方 API 对索引方法的约定是：找到时返回起止位置，找不到时返回 -1, -1。

go run .
# 预期关注 equal、start、end 三个字段，而不是先观察字符串是否被改写

这里还要注意一个工程细节：起止位置对应的是输入字节序列的范围，不能直接当成“第几个用户可见字符”。如果后续要按字符切片或在前端按 grapheme cluster 高亮，应在展示层另外处理索引单位，别把搜索 API 的返回值和界面光标位置混为一谈。

集成取舍：IgnoreCase、Loose、Exact 不是三个同义词

我在项目里最终保留了一个明确的选项表，因为“忽略大小写”经常被需求方扩大成“尽量把相似文字都算作一样”。这会改变搜索范围，必须显式选择。

官方文档还说明，Exact 会覆盖 ignore 选项。因此不要把配置写成“默认 Loose，再补一个 Exact，希望两者叠加”；应根据业务语义只选一条清晰路径。对登录名、文件名或协议字段，我通常先问清楚它们是“展示搜索”还是“身份标识”，再决定是否允许宽松匹配。

部署/集成：把语言标签和搜索规则放到配置边界

如果这个小工具要进 HTTP 服务，我会把语言标签从请求上下文或租户配置传入，并在服务启动时建立可复用的 Matcher。不要把一段 strings.ToLower 散落在 Handler、SQL 查询和前端代码里，否则同一个关键词在不同入口会得到不同结果。

type SearchService struct {
	matcher *search.Matcher
}

func NewSearchService(tag language.Tag) *SearchService {
	// Matcher 保存语言和选项，让服务层统一执行同一种搜索语义。
	return &SearchService{
		matcher: search.New(tag, search.IgnoreCase),
	}
}

func (s *SearchService) Contains(text, query string) bool {
	// 空查询是否命中由业务决定，这里把它显式视为未命中。
	if query == "" {
		return false
	}
	start, _ := s.matcher.IndexString(text, query)
	return start >= 0
}

Pattern 在官方文档中被描述为可安全并发使用；如果同一个查询会被大量请求重复执行，可以先编译 Pattern，再把它交给多个读取路径。这个优化不改变本文的核心判断：选项仍然在匹配器创建时确定，原文也不需要被提前转成小写。

验收：用六个问题确认没有把语义弄混

1. 语言标签是否真的对应用户文本，而不是无条件使用英语标签？
2. 需求要的是大小写不敏感，还是连变音符号和宽度也忽略？
3. 是否误把 Exact 和 IgnoreCase 叠加成一条含义不清的配置？
4. 业务是否需要保留原文，以便展示、审计或写回索引？
5. IndexString 返回的范围是否被正确理解为输入字节范围？
6. 高并发场景是否复用了明确配置的 Matcher 或 Pattern，而不是每个请求都重新拼规则？

我的结论是：ToLower 适合非常明确、只面向单一语言和简单 ASCII 约束的内部比较；一旦搜索面向多语言用户，IgnoreCase 的价值就在于它把“怎么相等”交给语言感知匹配层。它不是让所有文本都变得相同，而是让代码可以明确表达“在这个语言标签下，允许怎样的不区分大小写”。

常见问题

IgnoreCase 会自动忽略重音符号吗？

不会把所有宽松规则都混进来。官方选项定义中，IgnoreDiacritics 负责变音符号，IgnoreWidth 负责宽窄形式；需要组合这些行为时应考虑 Loose 或显式选项，而不是默认推断。

为什么不直接把两边都 ToLower 后比较？

因为这会先丢掉原文，并把语言相关的等价关系压缩成通用大小写转换。对于多语言名称和搜索词，业务真正需要的是“按哪个语言规则比较”，不是“把字节变成哪种大小写”。

Matcher 能在多个 goroutine 中复用吗？

文章中的服务结构可以把 Matcher 作为只读配置复用；如果进一步使用编译后的 Pattern，官方文档明确说明 Pattern 可安全并发使用。实际集成时仍应让语言标签和选项在创建阶段固定下来。