后缀数组构建慢？用 suffixarray 包 + 预排序优化：Go 标准库 suffixarray 构建为 O(n log n)，建议预构建序列化复用；Search 严格字节匹配，需正确处理 UTF-8 和 URL 解码；返回字节偏移，需自行维护行偏移映射；并发查询注意 GC 和缓存争用。
后缀数组构建慢？用 suffixarray 包 + 预排序优化
Go 标准库的 suffixarray 包（index/suffixarray）底层用的是倍增法（doubling algorithm），构建时间复杂度为 O(n log n)，对长文本（比如 >1MB）可能卡住几秒。别急着自己手写 DC3 或 SA-IS——先确认你是否真的需要在线构建。多数场景下，文本是静态或低频更新的，完全可以预构建并序列化。
实操建议：
- 用
suffixarray.New([]byte(text))构建后，立刻调用sa.WriteTo(writer)存到文件或缓存里，下次直接suffixarray.ReadFrom(reader)加载，跳过构建开销 - 如果文本会小范围追加（如日志流），不要反复重建整个 SA；改用滚动窗口 + 多个分段 SA，配合
Search后手动合并结果 - 注意：构建时内存峰值约 3–4 倍文本大小，
runtime.GC()无法立即释放中间切片，建议在独立 goroutine 中构建并用sync.Pool复用临时缓冲区
Search 返回空 slice？检查输入是否被截断或编码不一致
suffixarray.Search 只接受 []byte 模式串，且**严格按字节匹配**。常见错误是传入含 UTF-8 多字节字符的字符串但没转 []byte，或者模式串本身被截断（比如从 HTTP query 中取值时未处理 URL 解码）。
实操建议：
- 永远用
sa.Search([]byte(pattern))，而不是sa.Search([]byte(string(pattern)))——后者多余且易错 - 若 pattern 来自用户输入，先做
bytes.TrimSpace()和url.QueryUnescape()（如适用），再检查长度：len(pattern) == 0会导致返回空 slice，不是 bug 是设计行为 - Go 的
suffixarray不支持正则或模糊匹配，传入"a.*b"这类会被当作字面量搜索，找不到就安静返回[]int{}
查到位置却定位不到原字符串行号？得自己维护偏移映射
suffixarray.Search 返回的是字节偏移（[]int），不是行号或 Unicode 字符索引。如果你要高亮显示或跳转到第 N 行，必须额外建立文本结构索引。
实操建议：
- 构建 SA 前，先扫描一遍原文本，用
bytes.IndexByte找所有'\n'位置，存成[]int行首偏移表；查询后用二分查找确定匹配位置属于哪一行 - 避免用
strings.Split拆行再拼接——会丢掉原始换行符类型（\r\n还是\n），导致偏移错位 - 如果文本含大量非 ASCII 字符（如中文），别用
utf8.RuneCountInString(text[:offset])算字符数——它不等于字节偏移，仅用于显示宽度估算
并发查多个 pattern 性能反而下降？别让 SA 成瓶颈
suffixarray 本身是只读结构，理论上可安全并发调用 Search。但实际中，高频小 pattern 查询（如每秒上千次）可能因 cache line 争用或 GC 压力拖慢整体吞吐。
实操建议：
- 压测时观察
runtime.ReadMemStats().AllocsSinceGC：如果每次Search都触发小对象分配，说明 pattern 太短（字节），考虑提前缓存常见 pattern 的结果（LRU map ofmap[string][]int） - 不要在 handler 里反复调用
sa.Search处理单个请求的多个关键词；改用一次Search找出所有匹配位置，再用bytes.Equal二次过滤 pattern（适用于 pattern 集合固定且较小时） - SA 查找本质是二分 + LCP 比较，CPU 密集。若服务已满载，优先横向扩实例，而非纵向堆核——Go runtime 调度器对这种 workload 并不友好
后缀数组不是银弹：它快在“查”，慢在“建”和“内存”。真正难的不是实现 SA，而是决定什么时候不该用它——比如 pattern 动态变化频繁、文本小于 10KB、或需要前缀/正则语义时，strings.Index 或 regexp 反而更稳。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
