推荐用 os.Open + bufio.Scanner 逐行读取配合 strings.Contains 做轻量搜索，避免内存溢出；正则匹配用 regexp.Compile 预编译，多文件遍历用 filepath.WalkDir 加并发限流。
用 os.Open 读取文件并配合 strings.Contains 做简单匹配
大多数轻量级搜索需求（比如检查某行是否含关键词）不需要引入正则或全文引擎，直接读文件 + 字符串扫描最稳妥。注意别用 ioutil.ReadFile（已弃用），也别一次性加载超大文件到内存。
-
os.Open打开文件后，用bufio.Scanner逐行读取，避免 OOM - 对每行调用
strings.Contains(line, keyword)，区分大小写；如需忽略大小写，改用strings.Contains(strings.ToLower(line), strings.ToLower(keyword)) - 记得在循环外用
defer f.Close()，否则文件句柄泄漏 - 如果文件编码不是 UTF-8（比如 GBK），
bufio.Scanner可能截断或报错，此时需先转码，不能硬读
用 regexp.Compile 实现正则匹配与捕获
当要找“以数字开头的行”“邮箱格式字符串”或带上下文的模式时，正则不可少。Golang 的 regexp 包编译后可复用，但注意它不支持 PCRE 的部分语法（比如 lookbehind 在 Go 1.22 前完全不支持）。
- 提前编译正则：例如
r, _ := regexp.Compile(<code>^\d+.*$)，避免在循环里反复Compile -
r.FindString(line)返回首个匹配子串，r.FindAllString(line, -1)返回全部，r.MatchString(line)仅判断真假 - 若需提取分组（如邮箱用户名），用
r.FindStringSubmatch或r.FindStringSubmatchIndex，注意返回的是[]byte，需转string - 正则默认贪婪，但 Golang 不支持
.*?这种非贪婪修饰符的完整语义——实际行为依赖底层 RE2 引擎，某些复杂嵌套会退化为线性扫描
处理多文件时用 filepath.WalkDir 配合并发控制
搜整个目录树时，filepath.WalkDir 比递归 os.ReadDir 更可靠（能正确处理符号链接、权限拒绝等边界）。但默认是同步遍历，想提速就得加 goroutine —— 此时必须限流，否则可能打爆系统打开文件数或触发 “too many open files” 错误。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
sem := make(chan struct{}, 10)控制并发数（比如 10 个 goroutine 同时工作） - 每个 goroutine 开始前
sem ，结束后 <code> - 对每个文件路径，仍要用
os.Open+bufio.Scanner，不要把整个目录塞进一个 channel 再统一处理——文件 I/O 是瓶颈，不是 CPU - 遇到
permission denied错误时，WalkDir的回调函数返回filepath.SkipDir或nil即可跳过，无需 panic
大文件搜索避免内存爆炸的关键细节
超过 100MB 的文件，即使逐行读，也可能因某一行极长（比如 minified JS）导致单次 scanner.Text() 分配巨量内存。更稳的方式是用 bufio.NewReader + ReadBytes 或自定义缓冲区扫描。
立即学习“go语言免费学习笔记（深入）”；
- 设置 scanner 的最大行长：
scanner.Buffer(make([]byte, 4096), 1，第二个参数限制单行上限（如 1MB），超长则报 <code>bufio.ErrTooLong - 若必须处理超长行（如日志中的 base64 字段），改用
reader := bufio.NewReader(f); buf := make([]byte, 64*1024)，循环reader.Read(buf)手动滑动窗口匹配 - 正则在大文件中慎用
FindAllString，它会把所有匹配结果存进 slice——改用FindAllStringSubmatchIndex获取位置再切片，减少内存拷贝 - Linux 下可考虑调用
exec.Command("grep", "-n", keyword, path)借力系统工具，但要注意路径含空格或特殊字符时需shlex转义，且失去跨平台性
实际项目里，多数搜索场景卡在 IO 等待而非匹配逻辑，所以优先优化读取方式和并发粒度，而不是换更“高级”的匹配算法。另外，错误处理常被忽略：比如文件突然被删除、磁盘满、编码异常——这些都会让 scanner.Scan() 返回 false，但必须检查 scanner.Err() 才知道是不是真出错了。
