大文件秒级定位依赖os.Seek+io.ReadAt跳转而非全量读取；跳表等结构仅索引偏移元信息，value须存offset/length而非整行；倒排索引需预分块并建行偏移数组；suffixarray仅适用于静态大文本且高频查询场景。
大文件秒级定位不是靠“读得快”，而是靠“不读全量”——跳表、倒排索引、后缀数组这些结构本身不索引文件，只索引元信息或构建内存加速结构；真正在磁盘上跳转定位的，永远是 os.Seek + io.ReadAt 这类系统调用。
跳表只存 offset，别存整行内容
跳表（skip list）在 Go 里没有标准库实现，必须手写或引入第三方（如 github.com/google/btree 可改造成跳表语义）。但关键不是选哪个库，而是 value 存什么：
- 错误做法：
map[string]string存完整日志行 → 2GB 文件轻松吃掉 5GB 内存，GC 压力飙升 - 正确做法：
map[string][]struct{ offset int64; length int }，key 是可排序字段（如时间戳字符串、哈希前缀），value 只存偏移和长度 - 构建时必须用
os.Stat().Size()预估总行数，避免 slice 频繁扩容；插入前先sort.Search定位插入点，维持有序 - 查询后调用
file.Seek(offset, io.SeekStart)，再用io.ReadFull(file, buf[:length])精确读取，不依赖bufio.Scanner的临时切片（底层数组会被复用）
倒排索引适合关键词查文档ID，不适合查文件内偏移
倒排索引（map[string][]int）天然面向“文档集合”，不是单个大文件。若硬要用于文件搜索，需先将文件按块或按行切分为逻辑“文档”：
- 按行切分：每行一个
docID（即行号），分词后往idx[word] = append(idx[word], lineNo)写；查词后拿到行号列表，再用lineOffset[lineNo]查物理偏移（需预构建行偏移数组） - 按块切分（推荐）：固定 4KB/块，
docID是块序号；分词时记录词所在块号 + 块内偏移；查词后得到块号列表，再Seek到对应块首，局部扫描匹配 - 中文分词必须用
github.com/go-ego/gse，且设seg.WithFrequency(false)，否则每个词带频次字段，内存多占 30%+ - 停用词过滤不能放循环里反复
make([]string, 0)，直接预分配切片容量更省 GC
suffixarray 不是万能加速器，用错反而更慢
index/suffixarray 只在极少数场景值得用：文本稳定不变、长度 >10KB、后续查找 ≥200 次。其余情况，strings.Index 更快更省心：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 误用典型：用户每次输一个新关键词，就调一次
suffixarray.New(data)→ 构建耗时 20μs 起，比strings.Index的 30ns 慢 700 倍 - 正确用法：启动时对只读大文件（如日志模板、协议定义文本）构建一次
*suffixarray.Index，之后所有搜索复用它 -
Lookup(s, -1)返回的是字节偏移，含中文时若需截取完整字符，得用utf8.DecodeRuneInString(s[pos:])定位起始 rune，不能直接s[pos:pos+len(s)] - 输入超 2GB 会 panic：
runtime error: makeslice: len out of range，上线前必须加if len(data) > 2 校验
真正决定响应速度的，是 IO 路径是否绕过缓冲层
无论索引结构多漂亮，最终读文件那一下卡住，整个服务就卡住。常见瓶颈不在算法，而在系统调用链路：
- 别用
os.ReadFile加载大文件 → 全量进内存，且无法 Seek - 别用
bufio.NewReader(file).ReadString('\n')做随机行读取 → 内部缓冲区不可控，Seek 后位置错乱 - 必须用
os.OpenFile(path, os.O_RDONLY, 0)打开，配合file.Seek(offset, io.SeekStart)+io.ReadFull(file, buf) - 如果文件频繁更新，
os.Stat()获取 size 后立即被追加，需容忍io.ErrUnexpectedEOF并重试，而非 panic
最易被忽略的一点：索引结构和文件句柄必须共生命周期。跳表里存的 offset 对应的是当前文件版本，文件被 truncate 或重新生成后，所有 offset 失效——没有自动刷新机制，只能靠外部信号（如 inotify）触发重建。
