strings.Index 可替代 strings.Contains 避免重复扫描，因其返回位置且内部逻辑相同；多模式匹配应优先用 ahocorasick 库；小字符串拼接推荐 strings.Builder 或预分配 []byte；正则能不用则不用，strings 原生函数更高效。
用 strings.Index 替代 strings.Contains 避免重复扫描
strings.Contains 内部其实调用了 strings.Index，但只返回 bool；如果你后续还需要位置信息（比如截取、替换、分片），直接用 strings.Index 能省一次遍历。
常见错误是先 Contains 判断存在，再调 Index 找位置——这等于扫描字符串两遍。
- ✅ 正确做法：
pos := strings.Index(s, substr) if pos >= 0 { // 直接用 pos 做后续操作 rest := s[pos+len(substr):] } - ❌ 错误模式：
if strings.Contains(s, substr) { pos := strings.Index(s, substr) // 又扫一遍！ } - 注意：
strings.Index返回-1表示未找到，不是 panic，可安全判断
长文本多模式匹配优先用 ahocorasick 库而非循环调 strings.Index
当你要在一个大字符串里查十几个甚至上百个关键词（比如日志过滤、敏感词检测），逐个 strings.Index 是 O(n×m) 时间复杂度，性能断崖式下跌。
Aho-Corasick 算法把所有模式构建成自动机，单次扫描即可完成全部匹配，实际吞吐提升 5–50 倍（取决于模式数量和长度）。
立即学习“go语言免费学习笔记（深入）”；
- 安装：
go get github.com/BobuSumisu/ahocorasick - 构建自动机只需一次：
ac := ahocorasick.New(ahocorasick.Opts{ MatchOnlyOne: false, // 找到所有匹配 }) ac.Add([]byte("error"), "ERROR") ac.Add([]byte("warn"), "WARN") ac.Build() - 匹配时传入
[]byte，避免 string → []byte 重复转换开销 - ⚠️ 注意：自动机构建有内存开销，适合「模式固定、文本多变」场景；若每次模式都不同，别硬套
小字符串拼接别用 +，用 strings.Builder 或预分配 []byte
很多人以为 strings.Builder 只用于“大量拼接”，其实只要拼接次数 ≥ 3，它就大概率比 + 快，且内存更可控。
根本原因是：+ 每次都产生新字符串，触发多次堆分配和拷贝；Builder 复用底层 []byte，支持 grow 策略。
- ✅ 推荐写法：
var b strings.Builder b.Grow(len(prefix) + len(middle) + len(suffix)) // 预估长度，减少扩容 b.WriteString(prefix) b.WriteString(middle) b.WriteString(suffix) result := b.String()
- ⚠️ 不要这样：
s := prefix + middle + suffix + tail—— 编译器虽会优化两个字符串的 +，但三个及以上就失效 - 极端性能敏感场景（如网络协议序列化），直接操作
[]byte+copy更快，但需手动管理长度和编码（如 UTF-8 边界）
正则查找能不用就不用，strings 原生函数覆盖 90% 场景
regexp 包启动慢、编译耗 CPU、匹配过程无法内联，哪怕一个简单 \d+，也比 strings.FieldsFunc(s, unicode.IsSpace) 或手写字符扫描慢 3–10 倍。
多数需求其实不需要正则：提取数字？用 strconv.ParseInt 配合 strings.IndexByte；按分隔符切？strings.Split 或 strings.Index 循环更轻量。
- ✅ 替代方案举例：
// 想找第一个冒号后的内容 if i := strings.IndexByte(s, ':'); i >= 0 { value := s[i+1:] } // 想跳过前导空格和换行 start := 0 for start < len(s) && (s[start] == ' ' || s[start] == '\t' || s[start] == '\n') { start++ } trimmed := s[start:] - ⚠️
regexp.Compile是重量级操作，千万别在热路径里反复调用；必须用时，务必复用已编译的*regexp.Regexp实例 - UTF-8 安全提示：所有
strings函数操作的是字节索引，不是 rune 位置；若需按字符处理（如中文分词），得用utf8.DecodeRuneInString或strings.Reader
真正卡性能的往往不是单个函数选错，而是没意识到字符串操作隐含的内存分配和扫描次数。盯住 len()、Index、Substring 这些看似无害的操作在循环里的叠加效应，比纠结某个 API 的微秒级差异更重要。
