长文本优先用strings.index+bufio.scanner流式处理；短文本且需unicode支持用github.com/bobusumisu/ahocorasick并换算字符位置；单字符或固定双字节用bytes.indexbyte或bytes.index；优化前先用pprof定位真实瓶颈。
长文本场景下优先用 strings.Index + bufio.Scanner 流式处理；短文本（strings.Contains 或 strings.Index 即可，无需手写 KMP。
长文本搜索：为什么别自己读全文件再匹配
大文件（如日志、CSV）直接 ioutil.ReadFile 会 OOM，且无法中断或限流。真实瓶颈常在 I/O，不是匹配算法本身。
- 用
os.Open打开文件，配bufio.Scanner逐行扫描——内存占用恒定，不随文件大小增长 - 超长行（如 minified JSON）默认触发
scanner: token too long错误，需提前调大缓冲：scanner.Buffer(make([]byte, 4096), 1024*1024) - 避免
scanner.Text()后再调strings.Index：这会强制 UTF-8 解码并分配新 string；改用scanner.Bytes()+bytes.Index，对 ASCII 关键词快 2–3 倍
短文本匹配：标准库已足够，KMP 是伪需求
strings.Index 在短文本下实际走的是 memchr 或暴力匹配，不是 KMP；它自动适配输入长度，且无额外内存分配。
- 模式串 ≤ 64 字节时，标准库用无预处理的字节扫描，缓存友好，比手写 KMP 快 2–5 倍（尤其日志行查 “ERROR” 这类）
- 传空串给
strings.Index会 panic；你自己写的 KMP 若没加if len(pattern) == 0判断，同样崩溃——但标准库边界检查更可靠 - 含中文或 emoji 时，KMP 必须按字节操作；若你误把 string 转成
[]rune再喂给 KMP，匹配逻辑全错——而strings.Index天然支持 UTF-8 字节语义
多关键词 or 高频调用：别循环 strings.Index
查 10 个以上关键词，或每秒调用数百次，strings.Index 循环是性能黑洞——同一段内存被反复扫描，CPU cache 不友好。
- 简单正则（如
"GET|POST|HEAD"，无捕获组、无回溯），用regexp.MustCompile：Go 的 regexp 包会自动编译为 Aho-Corasick 类状态机，比循环快一个数量级 - 纯关键词集合（>50 个、不变）、需 Unicode 支持，用
github.com/BobuSumisu/ahocorasick；它返回字节偏移，需配合utf8.RuneCount换算字符位置 - 单字符或固定双字节（如
\r\n），直接上bytes.IndexByte或bytes.Index配[]byte("\r\n")，跳过 string 转换开销
真正要压榨匹配性能前，先用 pprof 确认瓶颈在 strings.Index 本身，而不是文件读取、正则编译或 GC 分配——多数时候，问题不在算法，而在数据流设计。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
