必须在循环外预编译，因每次regexp.compile都需语法解析、nfa构建与优化，开销远超匹配本身；固定正则应全局复用*regexp.regexp实例，动态pattern须用compile+err检查及quotemeta转义。
为什么 regexp.Compile 要在循环外预编译？
直接在遍历文件行时反复调用 regexp.Compile 会导致严重性能下降，尤其当正则表达式固定、搜索大量文件时。每次编译都涉及语法解析、NFA 构建和优化，开销远高于匹配本身。
- 预编译一次，复用
*regexp.Regexp实例，避免重复解析 - 若正则来自用户输入，需捕获
regexp.Compile的错误并提前返回，否则 panic 会中断整个搜索 - 注意：带
\Q...\E或regexp.QuoteMeta处理用户输入的特殊字符，否则.、*等会被当作元字符误匹配
逐行读还是整文件读？bufio.Scanner 和 io.ReadAll 怎么选？
取决于搜索场景：想定位到具体行号就用 bufio.Scanner；需要跨行匹配（如匹配含换行的模式）或文件不大（io.ReadAll。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
bufio.Scanner默认单行上限 64KB，超长行会报scanner.Token: too long，可调ScanLines或改用bufio.Reader.ReadString -
io.ReadAll一次性加载，内存占用高但支持Regexp.FindAllIndex获取所有匹配位置，再通过bytes.IndexByte反推行号 - 二进制文件或含 null 字节的文本，
bufio.Scanner会提前截断，必须用io.ReadAll+regexp.Match
如何安全地处理大文件而不 OOM？
关键不是“全读”，而是“分块流式扫描”——用 bufio.NewReader 配合滑动窗口，避免把整个文件塞进内存。
- 设定固定缓冲区（如 1MB），用
reader.Read循环读取，每次保留前一块末尾的未完成行（防止跨块匹配断裂） - 对每块内容执行
regexp.FindAllStringIndex，再偏移计算真实文件位置 - 跳过二进制判断：检查前 1024 字节是否含
\x00，有则按二进制处理（禁用 UTF-8 解码，匹配用[]byte） - Linux 下可用
os.Open+syscall.Mmap做内存映射，但 Windows 兼容性差，一般不推荐
匹配结果怎么带上下文行？
单纯 FindString 不够，得记录行号再前后拉取。但别边读边缓存全部内容——用环形缓冲区只存最近 N 行。
- 用
container/list或切片模拟固定长度队列，每读一行 push，超长则 pop front - 命中时，从队列中取出当前行及前后指定行数（如 -2,+2），拼成
context字段 - 注意：行尾换行符统一用
\n处理，Windows 文件可能含\r\n，建议先strings.TrimSuffix(line, "\r\n") - 如果要求高亮匹配关键词，用
strings.ReplaceAll包裹\033[31mANSI 转义（终端输出）或 HTML<mark></mark>（Web 输出）
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
