suffixarray 比 strings.Index 更适合多模式、高频搜索，因其预构建后缀数组实现 O(log n) 查询，而 strings.Index 是 O(n) 朴素扫描；但仅适用于固定文本多次查询场景，且需注意字节偏移、空值校验与内存管理。
为什么 index/suffixarray 比 strings.Index 更适合多模式、高频搜索？
index/suffixarray 预构建后缀数组，把字符串所有后缀按字典序排序并建索引，后续每次搜索是 O(log n)；而 strings.Index 是朴素的 O(n) 逐字符扫描。如果你要对同一段长文本（比如日志、代码块、配置内容）反复搜多个关键词，或者需要支持前缀/子串模糊匹配，suffixarray 的预处理代价能被摊薄。
- 构建耗时：对长度为
n的文本，构建时间约O(n log n)，内存占用约20n字节（实测 Go 1.22） - 单次查询快，但只对「固定文本 + 多次查询」场景划算；如果只查一次，它反而更慢、更占内存
- 不支持正则，也不支持大小写不敏感——得自己预处理文本（如全转小写）再建索引
怎么正确初始化 suffixarray.New 并避免 panic？
suffixarray.New 接收 []byte，不是 string，传错类型会编译失败；但它不检查空切片或 nil，传入 nil 会导致运行时 panic：panic: runtime error: makeslice: len out of range。
- 始终做非空校验：
if len(data) == 0 { return nil, errors.New("empty data") } - 不要用
string直接转：suffixarray.New([]byte(myString))是安全的，但注意大字符串会拷贝内存 - 如果文本来自文件，建议用
os.ReadFile后直接传[]byte，别中间转成string再转回[]byte
Finds 和 FindAllIndex 返回结果有什么本质区别？
Finds 返回所有匹配起始位置的 [][]byte 切片（实际是原数据的子切片引用），而 FindAllIndex 返回 [2]int 数组切片，每个表示 [start, end)。关键差异在语义和生命周期：
-
Finds返回的子切片共享原[]byte底层，只要原数据没被 GC，它们就有效；但若原数据是局部变量且函数返回后不再持有，可能引发静默数据错乱 -
FindAllIndex返回的是纯数值坐标，无内存依赖，适合存档、序列化或跨 goroutine 传递 - 两者都只找完全匹配的子串，不支持通配符；想实现“以某字符串开头”，得用
Lookup+ 手动二分找范围
为什么搜索中文或 UTF-8 多字节字符时结果看起来“偏移”了？
suffixarray 按字节操作，不感知 Unicode 码点。例如中文字符 "你好" 是 6 字节（UTF-8 编码），FindAllIndex 返回的 start 是字节偏移，不是 rune 偏移。如果你用 rune 索引去解释结果，就会错位。
立即学习“go语言免费学习笔记（深入）”；
- 搜索前统一用
[]byte处理：关键词也必须是[]byte，别混用string和rune切片 - 若需 rune 级定位（比如高亮第 3 个汉字），先用
FindAllIndex得到字节位置，再用bytes.Runes或utf8.DecodeRune转换计算 - 不要试图对
string做len()后直接减——那是 rune 数量，不是字节数
构建和查询本身不复杂，真正容易出问题的是对字节 vs rune、所有权 vs 引用、预处理时机这三处的误判。尤其当文本来自网络或用户输入时，空、超长、编码混杂这几个点，比算法逻辑更容易让服务挂掉。
