逐行迭代文件并用 re.search() 匹配，配合 re.compile() 预编译、enumerate() 获取行号、合理选用 flag 和编码容错，可高效处理大文本。
用 re.search() 逐行扫描，别加载全文到内存
大文本文件（比如几百 MB 或几 GB）根本不能用 readlines() 或 read() 一次性读入——内存会爆，Python 进程可能被系统 kill。正确做法是逐行迭代，对每行用 re.search(pattern, line) 判断是否匹配。这能保证内存占用基本恒定（只存一行 + 正则编译对象）。
常见错误是写成 re.findall(pattern, text) 对整个文件字符串操作，或者用 grep -P 后再用 Python 解析输出，多一层 IO 和进程开销，没必要。
- 用
open(file, 'r', encoding='utf-8', errors='ignore')避免编码报错中断（尤其日志混合编码时） - 提前用
re.compile(pattern)编译正则，避免在循环里重复编译 - 如果只需匹配行，不用捕获组，
re.search()比re.match()更安全（后者只从行首开始）
匹配结果要带行号？用 enumerate() 最轻量
很多场景（如日志分析、代码审计）需要知道匹配行在文件中的位置。别自己维护计数器变量，直接用 enumerate(f, start=1)，既清晰又无额外开销。
注意：行号是基于文本换行符计算的，Windows 的 \r\n 和 Linux 的 \n 都会被 for line in f 正确识别为一行，无需特殊处理。
立即学习“Python免费学习笔记（深入）”；
-
for lineno, line in enumerate(f, start=1):是标准写法，start=1让第一行编号为 1，符合人类习惯 - 如果后续要跳转到某行，记住
lineno是逻辑行号，不是字节偏移；真要随机访问得用linecache或预建索引 - 不要在循环里做耗时操作（如写磁盘、网络请求），否则会严重拖慢搜索速度
想提速？关掉 re.DOTALL 和不必要的标志
默认情况下 . 不匹配换行符，这对单行匹配完全够用。但有人习惯性加 re.DOTALL，以为“更全”，其实它会让正则引擎在内部做更多判断，实测在大文件中可使匹配变慢 10%–20%。
同样，re.IGNORECASE 在纯 ASCII 模式下影响不大，但如果 pattern 含 Unicode 字符（比如中文、emoji），开启它会让正则引擎启用更复杂的大小写映射表，性能下降明显。
- 只加真正需要的 flag：常用组合是
re.MULTILINE（让^/$匹配每行首尾）或re.UNICODE（确保 \w \d 等行为符合 Unicode 标准） - 如果 pattern 是固定字符串（无正则元字符），直接用
line.find(substring) != -1，比re.search()快 3–5 倍 - 避免在 pattern 中用
.*开头，尤其是贪婪匹配，容易引发回溯爆炸（比如匹配失败时反复尝试）
遇到超长行卡住？用 io.DEFAULT_BUFFER_SIZE 控制读取粒度
极少数文件含百万字符级的“单行”（比如 minified JSON、嵌入 base64 的日志），for line in f 可能卡住甚至 OOM。这时不能靠调大 buffering，而应改用按块读取 + 手动分隔。
但绝大多数情况不需要这么复杂。先确认是否真有超长行：head -n 1000 file | awk '{print length}' | sort -nr | head -1。超过 1MB 再考虑降级方案。
- 简单缓解：用
f = open(...); f.readline(1024*1024)限制单次读最大长度（但会破坏行完整性） - 稳健做法：用
io.BufferedReader(f, buffer_size=8192)+ 自己实现行缓冲，但代价是代码变复杂 - 更推荐：用
grep -nE 'pattern' file先粗筛，Python 再对返回的少量行做精细处理——混合工具链往往比纯 Python 更快
