bufio.Scanner 逐行读取比 ioutil.ReadFile 更安全，因后者将整个文件加载进内存易致 OOM，而前者默认 64KB 缓冲、边读边处理；超长行需手动调大 Buffer。
用 bufio.Scanner 逐行读取比 ioutil.ReadFile 更安全
大文件一加载就 OOM，不是 bug 是设计使然。Go 的 ReadFile 会把整个文件塞进内存，几 GB 日志直接卡死。而 bufio.Scanner 默认 64KB 缓冲，边读边处理，内存占用稳定在 KB 级。
注意默认扫描行长度上限是 65536 字节，超长行会报 scanner: token too long。真要处理超长日志（比如 minified JSON 行），得手动调大：
scanner := bufio.NewScanner(f) scanner.Buffer(make([]byte, 64*1024), 1<<20) // 最大支持 1MB 行
- 别用
strings.Contains做模糊匹配——它不支持正则，也区分大小写，灵活性差 - 如果只是固定字符串搜索，
bytes.Index比strings.Contains略快（避免 string 转 []byte 开销） - 带编码的文件（如 GBK 日志）必须先用
golang.org/x/text/encoding转 UTF-8，否则Scanner读出来就是乱码
正则匹配用 regexp.Compile 预编译，别在循环里 Compile
每次 regexp.Compile 都要解析、编译、生成状态机，开销不小。在 grep 工具里，模式通常是固定的（用户输一次），但若你在每行都调一次 Compile，10 万行就是 10 万次重复编译。
正确做法：启动时编译一次，复用 *regexp.Regexp 实例：
立即学习“go语言免费学习笔记（深入）”；
re, err := regexp.Compile(`\berror\b`)
if err != nil { /* 处理错误 */ }
// 后续用 re.MatchString(line) 或 re.FindAllStringIndex(line, -1)- 忽略大小写加
(?i)前缀，比如(?i)timeout，别用strings.ToLower全转小写——性能差且破坏原始格式 -
regexp.MatchString比re.FindString快一点，只判断存在性时优先用它 - 避免写
.*pattern.*这类贪婪正则，尤其在长文本中易回溯爆炸；用^.*pattern.*$更明确，但最好直接用re.MatchString不加锚点
多文件并发搜索别直接 go func() {}()，用 sync.WaitGroup + errgroup.Group
裸起 goroutine 容易漏错、难控制并发数、panic 会崩掉整个程序。grep 处理多个文件时，每个文件一个 goroutine 很自然，但必须能等全部完成、收集所有错误、限制最大并发（否则打开几千个文件句柄直接被系统 kill）。
errgroup.Group 是标准库推荐方案，自动传播第一个 panic/err，且支持上下文取消：
g, ctx := errgroup.WithContext(context.Background())
g.SetLimit(4) // 最多同时处理 4 个文件
for _, path := range files {
path := path // 防止闭包变量复用
g.Go(func() error {
return searchInFile(ctx, path, re)
})
}
err := g.Wait() // 等所有完成，返回首个非 nil error- 不传
context.Context就没法响应 Ctrl+C 中断，用户搜到一半想停，只能 kill -9 - 每个 goroutine 里打开文件后务必
defer f.Close()，不然 fd 泄露比内存还快 - 别用
runtime.GOMAXPROCS调并发数——那是调度器线程数，和你的 IO 并发无关
输出行号和文件名时，fmt.Printf 比字符串拼接更省 GC
频繁拼接 path + ":" + strconv.Itoa(lineNum) + ":" + line 会触发大量小对象分配，GC 压力明显。而 fmt.Printf 内部做了缓存和格式化优化，实测在百万行场景下快 15%～20%。
但要注意：不要在 hot path 里用 fmt.Sprintf 构造完整字符串再输出——它总要分配新字符串；直接 fmt.Printf 到 os.Stdout 即可：
fmt.Printf("%s:%d:%s\n", filepath.Base(path), lineNum, line)- 如果用户加了
-n只要行号，就别拼整行内容，提前continue - Windows 下路径分隔符是
\，但 grep 习惯用/统一显示，用filepath.ToSlash(path)标准化 - line 末尾自带换行符，
fmt.Printf末尾再加\n会导致空行，确认Scanner.Text()返回值是否已去 \n（默认是的）
真正麻烦的是二进制文件误判、编码探测失败、符号链接循环、权限拒绝这些边界情况——它们不常出现，但一旦出问题，用户第一反应不是看文档，而是觉得你这工具“不靠谱”。得在 open 文件前加 os.Stat 检查类型和权限，对 syscall.EISDIR 和 syscall.EACCES 单独提示，而不是让 panic 冒泡到终端。
