strings.Contains 是 Go 中最简模糊匹配方式，需注意大小写敏感、字段空值、UTF-8 中文支持、keyword 预处理及大数据量时的性能优化。
用 strings.Contains 做最简模糊匹配
Go 没有内置的“全文搜索”或“LIKE 查询”，最直接的方式就是遍历切片，对每个字段调用 strings.Contains。它大小写敏感，适合简单场景，比如后台管理中搜用户昵称、日志关键词。
常见错误是忽略大小写导致漏匹配：strings.Contains("Alice", "alice") 返回 false。如果需要忽略大小写，得先统一转小写：
strings.Contains(strings.ToLower(item.Name), strings.ToLower(keyword))
注意：频繁调用 strings.ToLower 会分配新字符串，若列表很大、keyword 很短，建议提前把 keyword 转一次小写，而不是每次循环都转。
结构体字段多时，别硬写 if-else 链
当要搜索 Name、Email、Description 多个字段，有人会写一长串 || 判断，可读性差且难维护。更稳妥的做法是提取一个搜索函数，用切片聚合待查字段值：
立即学习“go语言免费学习笔记（深入）”；
func match(item User, keyword string) bool {
fields := []string{item.Name, item.Email, item.Description}
kw := strings.ToLower(keyword)
for _, f := range fields {
if strings.Contains(strings.ToLower(f), kw) {
return true
}
}
return false
}
这样加字段只需改 fields 切片，不碰逻辑；也方便后续替换成正则或分词逻辑。
容易踩的坑：字段为 nil 指针（如 *string）或空结构体字段，strings.ToLower("") 没问题，但 strings.ToLower(nil) 会 panic。务必判空或解引用前检查。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
中文关键词搜索要注意 rune vs byte
Go 字符串底层是字节序列，strings.Contains 按字节匹配，对 UTF-8 编码的中文完全可用——只要 keyword 和目标字段都是合法 UTF-8 字符串，就不会出错。但别误以为“中文必须用 regexp”。
真正的问题常出现在边界场景：
-
strings.Contains("上海浦东", "上海")✅ 正常匹配 -
strings.Contains("上海浦东", "上海 浦")❌ 空格位置不对，不是模糊搜索的本意 - 用户输入了全角空格、破折号或 emoji，而数据里是半角或普通字符
这时候不是函数选错，而是要预处理 keyword：标准化空白符（strings.Map）、去除首尾空格（strings.TrimSpace），必要时做 Unicode 规范化（用 golang.org/x/text/unicode/norm）。不处理，搜“ＡＢＣ”永远找不到“ABC”。
性能敏感时，避免每次搜索都遍历全量数据
如果列表稳定、查询频繁（比如配置项列表被前端反复搜），别每次都 for range。可以预建索引：
- 按首字母分桶（适合关键词大概率靠前）
- 用
map[string][]int存 keyword → 匹配项下标（只适用于 keyword 固定且不多） - 引入轻量库如
bleve或go-fuzzy（但小项目杀鸡用牛刀）
更现实的权衡是：100 条以内，直接遍历；1000 条以上，考虑前端分页 + 后端限制单次搜索字段数；上万条，就该换专用搜索服务了。Go 的 strings.Contains 本身很快，瓶颈通常在内存带宽和 GC，而不是算法。
最容易被忽略的一点：搜索逻辑一旦嵌套在 HTTP handler 里，别忘了加超时或上下文取消——用户狂敲输入框触发连发请求时，旧的搜索 goroutine 可能还在跑，白白占资源。
