go中无法直接grep压缩文件，需用compress/gzip流式解压单个.gz文件，或用archive/zip遍历.zip包内文本文件并限制大小、跳过非文本项。
gzip 文件里直接 grep 行不通，得用 archive/zip 或 compress/gzip 解包再读
Go 没有内置的“压缩包内全文搜索”函数，grep -r 那套在 Go 里不适用。你不能把 zip 或 gz 文件当普通文本打开然后 strings.Contains —— 它们是二进制容器，内容被编码或压缩过。
真实场景分两类：
• 单个 .gz 文件（纯 gzip 流，比如日志压缩包）→ 用 compress/gzip
• .zip 包（含多文件、目录结构）→ 必须用 archive/zip 遍历条目
别试图用 os.Open + bufio.Scanner 直接扫 .zip，会读出乱码或 EOF 错误。
流式搜索 .gz 文件：用 gzip.NewReader 套 bufio.Scanner，别全加载进内存
对单个大 gz 文件（比如 2GB 的 access.log.gz），必须流式处理，否则 io.ReadAll 会 OOM。
关键步骤：
• 用 os.Open 打开文件 → 得到 *os.File
• 传给 gzip.NewReader → 得到解压后的 io.Reader
• 再包一层 bufio.NewReader（不是 Scanner 的默认缓冲！），避免行太长截断
• 用 scanner.Scan() 逐行读，scanner.Text() 拿内容
注意：gzip.NewReader 本身不校验 CRC32，如果源文件损坏，解压时才报 gzip: invalid checksum，建议加 defer greader.Close() 并检查 err。
遍历 .zip 并搜索所有文本文件：跳过二进制、控制解压大小、留意文件名编码
archive/zip 读 zip 是安全的，但容易踩三个坑：
• 不是所有条目都可读：有些是目录（fi.IsDir() 为 true）、有些是符号链接、有些权限不足 → 必须跳过
• zip 里可能混着图片/PDF/EXE，直接 rc, err := f.Open() 解压再 io.ReadAll 会爆内存 → 先用 f.UncompressedSize64 限制，比如 >50MB 的条目直接 skip
• Windows 打的 zip 常用 GBK 存文件名，Go 默认按 UTF-8 解析 → f.Name 可能是乱码，但搜索内容不受影响；真要处理路径，得用 github.com/mholt/archiver/v4 这类支持编码探测的库
示例逻辑片段：
for _, f := range r.File {<br> if f.IsDir() || !strings.HasSuffix(f.Name, ".log") && !strings.HasSuffix(f.Name, ".txt") {<br> continue<br> }<br> if f.UncompressedSize64 > 50*1024*1024 {<br> continue<br> }<br> rc, _ := f.Open()<br> // 后续 bufio.Scanner 流式读 rc<br>}
搜索性能和匹配精度：别用 strings.Contains 硬匹配，优先考虑 regexp 或带上下文的 bytes.Index
纯字符串匹配在日志场景下太脆弱：
• 时间戳格式变化（"2024-01-01" vs "Jan 01"）会让硬匹配失效
• 关键词可能跨行（比如 JSON body 换行）→ Scanner 按行切就漏了
• 大量 false positive（比如搜 "err"，结果匹配到 "error"、"terrible"）
建议：
• 简单关键词用 bytes.Contains（比 strings 快，且支持 []byte 流式输入）
• 模式复杂时用 regexp.MustCompile 编译一次，复用（别在循环里 MustCompile）
• 要上下文（比如匹配行+前后两行），就得自己维护一个滑动窗口 [][]byte，而不是依赖 Scanner
另外，gzip 解压本身有 CPU 开销，如果搜索条件极简单（如固定字符串），可以考虑先解压到临时 io.Pipe 再搜，避免反复解压同一份数据。
立即学习“go语言免费学习笔记（深入）”；
最麻烦的其实是 zip 包里嵌套 zip 或加密文件 —— Go 标准库完全不支持，遇到 zip: not a valid zip file 或 zip: encrypted file 就只能跳过。别指望流式搜索能覆盖所有归档变体，先明确你的输入来源是否可控。
