纯判断“有没有”选strings.contains，需位置信息或后续操作才用strings.index；空串恒返回true/0，须显式校验；utf-8兼容但不理解rune边界；多关键词查应避免重复扫描，优先用replacer或分词查map。

strings.Contains 和 strings.Index 该选哪个？

纯判断“有没有”，无条件选 strings.Contains；需要“在哪”或后续要切片、替换，才用 strings.Index。别用 strings.Index(s, substr) >= 0 替代 strings.Contains——它多算一次位置，实测慢 8%～12%，且语义模糊。

空字符串传给 Contains 或 Index 会怎样？

strings.Contains("any", "") 恒为 true，strings.Index("any", "") 恒为 0。这符合 Go 的设计约定（空串是任意字符串的子串），但容易在配置校验、关键词过滤等场景引发逻辑漏洞。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 若业务上“空关键词”应视为非法，必须显式检查 substr == "" 并提前返回错误
• 别依赖这个行为做默认值兜底，尤其在用户输入未清洗时

中文、emoji 或带修饰符的 Unicode 字符能用 Contains 正确匹配吗？

可以，只要子串本身是合法 UTF-8 片段。strings.Contains 工作在字节层面，对标准 UTF-8 编码完全兼容。但注意：它不理解 rune 边界。

• 错误做法：用下标截取中文字符串再查，比如 s[0:3] 可能切出半个汉字，导致 Contains 失败
• 正确做法：需按字符切片时，先转 []rune，再取 string(runes[i:j]) 构造子串
• 组合字符（如 ?‍?、à）若被截断，Contains 仍会按字节比对，结果不可靠

同一主串查多个关键词时性能怎么优化？

反复调用 strings.Contains 是最差选择——每次从头扫描，时间复杂度 O(n×m) 累加。Go 1.22+ 虽对 ASCII 子串启用了 SIMD，但中文等 Unicode 子串仍走朴素匹配。

• 查 2～5 个固定关键词：用 strings.Index 循环 + 记录偏移，扫一遍主串搞定
• 查动态关键词（如用户搜索）：预构建 *strings.Replacer 或用 strings.FieldsFunc 分词后查 map[string]bool
• 主串极大（如文件内容）、子串极短：改用 bytes.Index，省去 string → []byte 转换开销

实际写法里最容易被忽略的是：**你到底需不需要位置信息**。一旦误把 Index 当 Contains 用，不仅慢，还埋下索引越界或切片错位的隐患。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！