go语言无内置全文搜索，小文件用io.readall+strings.contains，大文件须用bufio.scanner逐行处理防oom；注意scanner默认64kb行限制及大小写、utf-8兼容性。
Go 语言本身不提供内置的“全文搜索”函数，但用 os.Open + bufio.Scanner 或 io.ReadAll 配合 strings.Contains 就能高效完成大多数文件内容搜索任务——关键不是用什么高级库，而是别在大文件里直接 io.ReadAll 导致 OOM。
小文件直接读全量 + strings.Contains
适合几 MB 以内的配置文件、日志片段或模板文件。优点是代码最简，逻辑清晰。
常见错误：对超大文件（如 500MB 日志）也这么干，进程直接被系统 kill。
- 用
os.ReadFile一次性读入内存，再用strings.Contains判断 - 若需定位行号，改用
strings.Index+bytes.Count统计换行符个数（注意 Windows 的 - 区分大小写：默认敏感；忽略大小写用
strings.Contains(strings.ToLower(content), strings.ToLower(keyword))，但注意非 ASCII 字符（如中文）没问题，UTF-8 安全
大文件逐行扫描避免内存爆炸
日志分析、审计场景常见需求。核心是不让整文件进内存，靠 bufio.Scanner 流式处理。
容易踩的坑：Scanner 默认单行上限 64KB，遇到超长行会报 scanner: token too long 错误。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
scanner := bufio.NewScanner(file)，循环scanner.Scan() - 调
scanner.Text()获取当前行，再用strings.Contains匹配 - 若文件含超长行，加
scanner.Buffer(make([]byte, 64*1024), 1 扩容缓冲区（第二个参数是最大 token 长度） - 记得检查
scanner.Err()，IO 错误（如权限不足、磁盘损坏）会在这里暴露
支持正则匹配时优先用 regexp.Compile 预编译
需要模糊匹配（如 “error.*timeout”）、提取分组时必须上正则。但别在循环里反复 regexp.Compile，性能会断崖下跌。
典型错误现象：搜索 10 万行耗时从 200ms 涨到 12s，就是因为每行都重编译一次正则。
- 把
regexp.Compile提到循环外，复用*regexp.Regexp实例 - 简单子串搜索不用正则——
strings.Contains比re.MatchString快 5–10 倍 - 若需高并发搜索多个文件，注意
*regexp.Regexp是并发安全的，可共享
跨平台路径与编码问题实际怎么处理
Go 文件操作默认 UTF-8，但 Windows 上用户可能存 GBK 编码的日志，Linux 上也可能遇到 ISO-8859-1 的旧数据——Go 不自动转码，搜不到不是代码错，是编码不匹配。
最常被忽略的一点：没人告诉你 os.Open 根本不关心文件编码，它只管字节流。
- 先用
file, err := os.Open(path)打开，再用io.ReadAll或Scanner读原始字节 - 若怀疑非 UTF-8，用
golang.org/x/text/encoding包转换（例如unicode.UTF8.NewDecoder().Bytes(data)只是兜底，实际得按 BOM 或统计判断编码） - Windows 路径分隔符用
filepath.Join，别硬写"\\"；搜索关键字含反斜杠时，Go 字符串要双写："C:\\temp"
真正难的不是写几行搜索代码，而是想清楚：这文件多大？是否可能被其他进程写入？要不要支持通配符？有没有敏感词需要脱敏？这些决定了你该用 Scanner 还是 mmap，该加锁还是走 channel。别一上来就抄个“高性能全文检索”方案——90% 的场景，os.Open + bufio.Scanner + strings.Contains 就够了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
