suffixarray.new 比 strings.index 慢因构建后缀数组需 o(n log n) 预处理，适合同一长文本（>10kb）上百次搜索；单次或少量搜索应直接用 strings.index。
suffixarray.New 为什么比 strings.Index 慢很多？
因为 suffixarray.New 构建的是后缀数组索引，本质是预处理——它适合「同一字符串上反复搜索多个模式」；而 strings.Index 是纯暴力扫描，单次搜索开销小，但重复搜就反复遍历。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 如果只搜一次或几次，别用
suffixarray，直接strings.Index或strings.Contains - 如果对一个长文本（比如 >10KB）要执行上百次不同子串查找，才值得调用
suffixarray.New一次，再复用Search -
suffixarray.New时间复杂度 O(n log n)，内存占用约 4×原文本长度（Go 1.21+），短文本上纯亏
Search 返回的 []int 是什么？怎么用？
它返回所有匹配起始位置的下标切片，按升序排列，不是布尔值也不是单个位置。容易误以为「找到就该停」，其实它默认穷举全部匹配。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 要找第一个匹配：取
result[0]（需先判空） - 要限制数量避免全扫：手动 break 循环，
suffixarray本身不支持 limit 参数 - 注意返回的是字节偏移，不是 rune 偏移——含中文时，直接用它切字符串可能 panic，得先转
utf8.RuneCount或用bytes.Index辅助
构建失败 panic: runtime error: makeslice: len out of range
这是 suffixarray.New 对超长输入的保护机制触发了，内部某些中间切片计算溢出。常见于 >2GB 的字节切片（即使机器内存够），Go 标准库未做优雅降级。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 上线前加长度校验：
if len(data) > 1 - 不要传
io.Reader直接到suffixarray.New——它只接受[]byte，必须先读全再判断 - 替代方案：对超大文本，改用流式匹配（如
regexp+bufio.Scanner）或外部工具（grep -o）
和 regexp 匹配相比，suffixarray 能不能支持通配符？
不能。suffixarray.Search 只支持精确子串匹配，所有字符必须逐字相等。它不解析正则、不支持 *、?、. 等任何元字符。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 需要模糊/通配/正则语义，别硬套
suffixarray，直接上regexp.Compile - 若只是「前缀匹配」，用
strings.HasPrefix更快更安全 - 若要「多模式同时匹配」（比如 AC 自动机场景），标准库没提供，得用第三方如
github.com/BurntSushi/aho-corasick
后缀数组真正的价值不在单次搜索，而在「预建索引 + 多次随机子串定位」这个组合。一旦用错场景，它就成了最慢的字符串查找方式。
