strings.Index 比 Contains 更高效，只需一次扫描即可获取位置并复用；固定ASCII前缀查找优先用 bytes.IndexByte；多模式匹配应使用 Aho-Corasick 算法；正则须预编译避免循环中重复解析。
strings.Index 比 strings.Contains 更快，但很多人用错了
如果你只判断是否存在，strings.Contains 没问题；但只要后续还要位置（比如截取、替换、分片），就别先 Contains 再 Index——这等于把同一段字符串扫两遍。
真实服务里常见于 HTTP 头解析、日志字段提取等场景，一次 strings.Index 就能拿到位置并复用，内部逻辑和 Contains 完全一致，只是多返回一个 int。
- ✅ 正确写法：
pos := strings.Index(s, "Content-Length:")，然后直接用pos做切片或跳过前缀 - ❌ 错误模式：
if strings.Contains(s, "Content-Length:") { pos := strings.Index(s, "Content-Length:") } - 注意：
strings.Index返回-1表示未找到，不是 panic，可安全用于条件分支
长文本+固定前缀？优先用 bytes.IndexByte
很多“字符串查找”本质是找协议分隔符或固定字节序列，比如 "
"、"GET "、"{"。这时 bytes.IndexByte 能绕过 UTF-8 解码开销，直接操作底层字节，比 strings.Index 快 2–5 倍。
但它只认单字节，不能用于中文或任意 rune；若目标确定是 ASCII（如 HTTP/JSON 协议字段），这就是最轻量的加速点。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 用
[]byte(" ")配合bytes.Index查双字节序列，比strings.Index少一次string → []byte转换 - 若模式首字节固定（如所有候选都以
'G'、'P'开头），可用map[byte][]string分组 +bytes.IndexByte定位后局部比对，避免全局扫描 - 不要在循环里反复调
[]byte(s)，提前转好复用；Go 1.20+ 可用unsafe.String+unsafe.Slice零拷贝转换
多模式匹配别硬套 strings.Index 循环
同时查十几个关键词（如日志中匹配 "error"、"timeout"、"404"）时，逐个 strings.Index 是 O(n×m)，CPU cache 友好性差，且无法复用预处理结果。
真正该上的是 Aho-Corasick：建树一次，后续每次扫描都是 O(n + m)，吞吐提升 5–50 倍。第三方库 github.com/BobuSumisu/ahocorasick 无 CGO、支持 Unicode、内存紧凑。
- 构建时过滤空字符串，否则
ac.Add会 panic - 输入必须是
[]byte，pattern 和 text 都按 UTF-8 字节序列处理；不自动对齐 rune 边界，含中文时需确保切片位置合法 - 回调函数里只存
{Start, End}，别做阻塞操作（如网络请求、文件写入），否则拖慢整个扫描流
正则匹配别在循环里 regexp.MustCompile
如果模式带通配、可选或重复（如 "(error|warn):.*\d{4}"），别自己手写状态机——Go 的 regexp 包编译后足够快，且已做 Thompson NFA 优化。
但必须预编译：每次调 regexp.MustCompile 都会重新解析、生成指令流、分配内存，开销远超匹配本身。
- 包级变量或结构体字段缓存
*regexp.Regexp实例，复用即可 - 只需判断存在用
MatchString，比FindStringIndex更轻量 - 避免
.*开头的表达式，易触发回溯爆炸；优先用[^ ]*等明确字符类
string 子串会触发 runtime.slicebytetostring 分配，高频调用下 GC 压力陡增；更稳妥的做法是接口返回 int 偏移或 struct{Start, End int}，由调用方按需切片。 
