strings.Contains仅做字节级子串匹配，不区分位置；需前缀/后缀判断应使用HasPrefix/HasSuffix，注意空字符串恒为true、大小写敏感、Unicode归一化及bytes与strings包区别。
strings.Contains 用对了，但结果不对？检查是否混淆了子串和前缀/后缀
Go 的 strings.Contains 只做纯子串查找，不区分位置——它不会告诉你匹配发生在开头、中间还是结尾。如果你实际想判断“是否以某字符串开头”，该用 strings.HasPrefix；想判断结尾，用 strings.HasSuffix。混用会导致逻辑漏洞，比如验证 API 路径时误把 /user/profile 当作 /user 的合法子路径（其实它是，但语义上不该靠 Contains 判定）。
常见错误现象：
– 输入 strings.Contains("/api/v2/users", "/api/v1") 返回 false（正确），但有人误以为它该返回 true 因为“都带 /api”——它只认字面连续出现
– 把空字符串 "" 传给 substr 参数，strings.Contains("hello", "") 恒为 true，这在边界校验中容易引发意料外的通过
- 永远显式检查
substr是否为空，除非你明确需要“空字符串总是存在”这个行为 - 若需多关键词任意匹配（如日志里含 "error" 或 "timeout"），别链式调用
Contains，改用strings.Index+ 循环或正则 - 大小写敏感是默认行为；不区分大小写请先用
strings.ToLower统一转换，不要依赖第三方包做简单场景
性能敏感场景下，避免反复调用 strings.Contains 做同一主串的多次子串扫描
每次调用 strings.Contains 都会从头遍历主串，时间复杂度 O(n×m)（n 是主串长，m 是子串长）。如果要在同一字符串上查 5 个关键词，重复扫描 5 次，不如一次性扫一遍，用 strings.Index 或 bytes.Index 记录所有命中位置。
使用场景：
– 日志行过滤（单行含多个关键字才上报）
– 配置值白名单校验（字段值必须包含至少一个允许的协议标识）
立即学习“go语言免费学习笔记（深入）”；
- 对固定主串+动态子串（如用户输入关键词搜索），考虑预构建
*strings.Replacer或用strings.FieldsFunc分词后查 map - 若主串极大（如读取文件内容），且子串较短，
bytes.Index比strings.Contains略快（底层跳过字符串转字节切片开销） - 注意：Go 1.22+ 对
strings.Contains做了自动 SIMD 优化，但仅限 ASCII 子串；含中文等 Unicode 字符时仍走朴素算法
中文或 emoji 字符串里用 Contains 出现“找不到明明存在的子串”？确认 rune 边界没被破坏
Go 字符串底层是字节序列，strings.Contains 按字节匹配。大多数时候没问题，但遇到组合字符（如带声调的汉字、emoji 修饰符序列）时，若子串提取方式不当（比如用下标截取而非 string([]rune(s)[i:j])），会导致字节层面不一致。
常见错误现象：
– s := "??"（ZWNJ 连接的程序员 emoji），用 s[0:4] 截出的不是完整字符，再拿它去 Contains 就永远失败
– strings.Contains("café", "é") 在某些编码来源下返回 false，因为 “é” 可能是单个 Unicode 码点（U+00E9），也可能是 e + ◌́（U+0065 U+0301）组合形式
- 优先用
strings.Contains处理原始输入，不要自己切片后再查——除非你控制全部数据源且确认编码归一化 - 涉及用户输入或外部接口返回的字符串，先用
norm.NFC.String(s)归一化（需导入golang.org/x/text/unicode/norm） - 简单判断 emoji 存在性，比对
rune切片更可靠：用for _, r := range s { if r == '?' { ... } }
strings.Contains 在 bytes 和 strings 包里有同名函数，别导错包
Go 标准库有两个 Contains：strings.Contains 和 bytes.Contains。前者参数是 string, string，后者是 []byte, []byte。类型不匹配会编译报错，但有时你会意外把 []byte 转成 string 再传给 strings.Contains，导致二进制数据被解释为 UTF-8——如果原字节含非法 UTF-8 序列，转换会变成 ，后续匹配必然失败。
使用场景：
– 读取文件二进制内容（如 PDF 片段、网络包 payload）
– 处理 base64 解码后的原始字节
- 如果操作对象本质是字节流（哪怕内容是文本），优先用
bytes.Contains，避免无谓的 string 转换 - 不确定输入是 string 还是 []byte？写两个重载函数，或统一收口为
interface{}+ 类型断言（但通常不值得，直接约定类型更清晰） - 别为了少敲几个字母 import
"bytes"却在代码里写bytes.Contains("hello", "ll")——编译不过，且 IDE 不一定高亮提示
真正麻烦的从来不是“能不能找到”，而是“为什么在这个上下文里找得不对”。Unicode 归一化、字节 vs rune、大小写策略、还有那些藏在日志里没打出来的空格和不可见字符——它们不会报错，只会让 Contains 返回 false，然后你花二十分钟翻文档，最后发现是前端多传了个 \u200b
