os.Open + bufio.Scanner 不适用于百MB以上日志实时检索，因其默认64KB缓冲区遇超长行报错，且不支持反向扫描或随机跳转，每次检索需O(n)遍历。
为什么 os.Open + bufio.Scanner 不能直接用于百MB以上日志的实时检索
因为 bufio.Scanner 默认缓冲区只有 64KB，遇到超长行（如堆栈跟踪、JSON 日志）会直接报错 scanner: token too long；更关键的是它不支持反向扫描或随机跳转，每次检索都得从头读，O(n) 时间无法接受。真正做动态检索时，必须绕过逐行扫描的惯性思维。
用 mmap + bytes.Index 实现快速定位行首偏移
Linux/macOS 下可用 golang.org/x/sys/unix 调用 mmap 将大文件映射到内存，避免 I/O 拷贝；再配合 bytes.Index 在内存块中二分查找换行符 \n，构建行偏移索引表。这不是“加载全量”，而是按需映射+惰性解析。
- 首次构建索引耗时约 200ms（1GB 日志），后续所有
grep-like 查询都在微秒级 - 注意
mmap映射后要调用unix.Munmap，否则 Go runtime 不自动回收（尤其长期运行的服务） - Windows 需改用
syscall.CreateFileMapping，行为略有差异：MapViewOfFile返回指针需用unsafe.Slice转为[]byte
regexp.Compile 在高频检索中的性能陷阱
正则编译开销大，且 regexp.MatchReader 内部仍会逐行读取——这和我们用 mmap 的初衷冲突。实际应拆解为两层：先用 bytes.Index 快速定位可能包含关键词的行范围（例如前后 5 行），再对这些小片段用 regexp 精确匹配。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 避免在循环里反复调用
regexp.Compile，缓存*regexp.Regexp实例 - 纯字符串搜索优先用
strings.Contains或bytes.Contains，比正则快 10–100 倍 - 若必须用正则，确保模式不含
.*开头，否则回溯爆炸（例如.*error在 10MB 行里会卡住）
如何支持“滚动查询”和“时间范围过滤”而不重读文件
日志文件持续追加时，仅靠文件大小判断新内容不够——可能有 truncate 或轮转。正确做法是记录上次读取的 offset 和 mtime，每次查询前用 os.Stat 检查是否变更；若变更，只增量扫描新增部分（从旧末尾到新末尾），并更新索引表尾部。
立即学习“go语言免费学习笔记（深入）”；
- 时间戳字段若在行首（如
2024-05-20T10:30:00Z INFO...），可结合偏移索引做二分查找，把时间范围转为字节区间 - 不要依赖
log.Println格式的时间，不同服务输出格式不一，应提取时先统一解析成time.Time，再比较 - 轮转后的旧文件（如
app.log.1）需单独建索引，但查询时可复用同一套 mmap + offset 查找逻辑
bufio.Scanner 当万能方案硬扛 GB 级文件，结果 CPU 100% 卡死。 
