应提前编译正则为包级变量：静态模式用regexp.MustCompile，动态模式用regexp.Compile并检查err；启用多行模式需加(?m)前缀；提取子匹配时注意[][]byte结构及索引安全。
直接用 regexp 包配合逐行读取即可完成文件内容的正则匹配，不需要加载全文、不依赖第三方库，但必须注意编译复用、多行标志和子匹配提取方式这三个关键点。
如何正确编译并复用正则对象
每次在循环或高并发搜索中调用 regexp.Compile 或 regexp.MustCompile 都会带来明显性能开销，尤其当正则固定（如日志关键字、配置项模式）时，应提前编译为包级变量。
- 静态 pattern（如
^ERROR:、\d{4}-\d{2}-\d{2}）——用regexp.MustCompile，错误在启动时暴露，避免运行时 panic - 动态 pattern（如用户输入的搜索词）——必须用
regexp.Compile并检查err，否则nil指针调用FindString会直接 panic - 别在
filepath.Walk回调里重复编译；哪怕只搜一个文件，也建议把*regexp.Regexp作为参数传入，而非每次新建
为什么 ^ 和 $ 默认不匹配每行开头结尾
Go 的 regexp 默认关闭多行模式（m 标志），所以 ^ 只匹配整个输入字符串开头，$ 只匹配结尾。对文件逐行扫描时，若想让 ^ERROR 匹配某一行的起始，有两种等效写法：
- 显式加
(?m)前缀：(?m)^ERROR—— 推荐，语义清晰，不影响其他逻辑 - 用
\A和\z替代（它们始终锚定全文本首尾，与m无关） - 错误示范：
^ERROR$不加(?m)且用于单行文本时看似有效，但一旦换行符混入或传入整段内容就会失效
提取匹配行号和捕获组时的常见陷阱
逐行读取 + FindStringSubmatch 是最常用组合，但返回值类型容易误用：它返回的是 [][]byte（二维切片），不是 []string，且每个子切片第一个元素是完整匹配，后续才是括号捕获组。
立即学习“go语言免费学习笔记（深入）”；
- 若正则无括号（如
ERROR.*），FindStringSubmatch返回的[][]byte只有一个元素，subs[0]就是整行匹配内容 - 若有括号（如
(ERROR): (.*)），需确保取subs[1]（第一组）、subs[2]（第二组），而不是直接string(subs[1])忘记索引越界风险 - 别用
FindAllString替代——它丢弃所有分组信息，只留主匹配字符串，无法还原结构化字段 - 行号需手动维护：在
scanner.Scan()循环中用计数器累加，scanner.Text()返回当前行，scanner.Bytes()更适合含二进制或非 UTF-8 数据的场景
真正难的不是写对正则，而是当文件夹下有几百个 100MB 日志文件、用户同时提交多个模糊 pattern 时，如何控制 goroutine 数量、避免内存暴涨、以及在匹配失败时快速定位是正则语法错还是 Unicode 范围写窄了——这些细节不会报错，但会让搜索结果静默丢失。
