strings.Index 是多数单次/低频搜索的最优解；suffixarray 仅适用于高频、长文本、可预建索引场景，误用反致性能下降。
别直接上 suffixarray —— 大多数场景下它反而拖慢搜索速度。 真正的高性能内存搜索，取决于你搜什么、搜几次、文本多长、是否需要模糊匹配。硬套标准库或第三方索引库，常因误判场景而引入额外开销。
strings.Index 仍是绝大多数单次/低频搜索的最优解
Go 标准库的 strings.Index 是纯字节扫描，无预处理、无内存占用、无构建延迟。对短文本（
- 适用场景：HTTP 日志行过滤、配置文件关键词提取、模板渲染中的一次性变量占位符查找
- 注意点：
strings.Index返回字节偏移，含中文时若需按字符切分，得先用utf8.RuneCountInString(s[:pos])转换，否则s[pos:pos+len(keyword)]可能 panic - 性能对比：在 5KB 字符串中查一个 3 字符子串，
strings.Index平均耗时 ~30ns；而suffixarray.New+Search组合首次调用超 20μs（含构建），仅当后续搜索达 300+ 次才可能回本
suffixarray.New 只在「长文本 + 百次以上随机子串查找」时值得用
suffixarray.New 的价值不在单次快，而在复用。它构建 O(n log n) 后缀数组，内存占用约 4×原文本长度（Go 1.21+），之后每次 Search 是 O(m log n)（m 为模式长度），接近二分效率。
- 必须满足：文本长度 >10KB 且稳定不变；搜索模式完全不可预测（非前缀/非固定集合）；总搜索次数 ≥200
- 常见误用：把用户输入的单个关键词丢给
suffixarray.New构建——这等于为查一次花 10ms 建索引 - 返回值是
[]int，不是 bool 或单个 int：要第一个匹配就取result[0]（先if len(result) == 0判空）；想限制只找前 5 个，得手动循环 break，suffixarray不支持 limit 参数 - 构建失败报
panic: runtime error: makeslice: len out of range？说明输入 >2GB，标准库未做降级，上线前务必加if len(data) > 2 校验
需要多模式或通配语义？regexp 或 aho-corasick 才是正解
suffixarray.Search 只做精确子串匹配，不支持 .、*、?、字符类等任何正则元字符。强行用它“模拟”前缀匹配，不如直接用 strings.HasPrefix —— 后者是 O(m) 且零分配。
- 多个固定关键词同时查找（如敏感词过滤）：用
github.com/BurntSushi/aho-corasick，构建一次 AC 自动机，搜索 O(n+m)，远优于循环调用strings.Index - 需要正则逻辑（如邮箱、URL 提取）：直接
regexp.Compile，别试图绕过；现代 regexp 引擎已高度优化，对简单模式甚至比手写状态机还快 - 纯前缀场景（如路由匹配）：
sort.Strings+sort.SearchStrings做二分查找，或用github.com/google/btree维护有序 key 集合
高频小数据搜索，优先考虑预计算 + map 查找
如果搜索目标集很小（比如几百个固定 ID）、且被查文本也固定（如配置项白名单），最高效方式根本不是字符串算法，而是提前建 map[string]bool 或 map[string]int。
- 例如解析 CSV 表头后，把列名映射到索引：
headerMap := map[string]int{"user_id": 0, "email": 1, ...}，后续每行headerMap["email"]是 O(1) 且无 GC 压力 - 若需支持大小写不敏感，建 map 前统一转
strings.ToLower，别在每次搜索时重复调用 - 注意：map 查找虽快，但键过多（>10w）时哈希冲突上升，可考虑用
bigcache分片机制或切换为btree等有序结构
真正卡性能的往往不是算法本身，而是没意识到「搜索」在你的系统里到底是什么动作：是用户实时输入的模糊补全？是离线日志的批量关键词扫描？还是服务启动时一次性的配置加载？选错抽象层，再快的 suffixarray 也是负优化。
