linecache.getline() 对超大文件看似高效实则危险，因首次调用即全量加载文件到内存并缓存所有行，导致GB级文件瞬间占用大量内存。
linecache.getline() 为什么对超大文件“看似高效”但实际有陷阱？
linecache.getline() 看起来是读取某行的捷径——传入文件路径和行号，直接返回字符串。但它内部会把整个文件缓存进内存（以字典形式按文件路径索引），首次调用时触发全量读取+逐行分割。这意味着：即使你只想要第 100 万行，它也会把前面 999,999 行全 load 进内存，还建一个 dict 存所有行。对 GB 级源码文件，这等于瞬间吃掉数 GB 内存，且后续再读同一文件其他行才变快。
所以它只适合「反复读取同一文件的多行」且「文件本身不大（linecache。
真正高效的方案：用 seek() + 逐行定位，避开全文件加载
核心思路是跳过前 N−1 行，只读目标行。Python 自带的 enumerate() 配合 open() 是最轻量、最可控的方式，不依赖额外模块，也不缓存无关内容。
- 用
for i, line in enumerate(f, 1)，当i == target_line时直接break，拿到line就停 - 避免用
readlines()或list(f)—— 它们会一次性把全部行加载进内存 - 如果目标行号很大（比如 1000 万行），这个循环仍要执行 1000 万次
next()调用，但每行只分配一次字符串对象，内存占用始终是 O(1) - 注意：文件必须是文本模式（
'r'），且换行符为\n或\r\n（Python 自动处理）
def get_line_by_number(filepath, n):
with open(filepath, 'r', encoding='utf-8') as f:
for i, line in enumerate(f, 1):
if i == n:
return line.rstrip('\n\r')
return None # 行号超出范围需要随机多次访问？自己构建行偏移索引表
如果你要频繁查不同行（比如调试器跳转、符号表解析），重复遍历太慢。这时可以预先扫描一次文件，记录每行开头的字节偏移，存在 list 里（offsets[i] = 第 i 行起始位置）。之后用 seek() 直接跳转，再 readline()，时间复杂度 O(1) 每次查询。
立即学习“Python免费学习笔记（深入）”；
- 构建索引只需遍历一次：用
f.tell()记录每行开始位置，f.readline()推进 - 索引表大小仅是整数列表，1000 万行 ≈ 80MB（64 位系统），远小于原文件
- 读取时：先
f.seek(offsets[n-1])，再f.readline()，注意处理最后一行无换行符的情况 - 缺点：索引不支持文件动态变更；二进制文件或含 \0 的文本需额外处理
linecache 在什么情况下真能用？
只有两个条件同时满足时，linecache.getline() 才算合理选择：
- 你要读的是「小文件」（如 Python 源码，通常
- 你控制整个生命周期：调用
linecache.clearcache()在不再需要时释放内存，否则缓存一直占着不放 - 别指望它加速单次读取；也别传入
None作为 filename 去“读标准输入”——它只认磁盘路径 - 错误示例：
linecache.getline('huge.log', 5000000)→ 内存爆掉；正确做法是用上面的enumerate方案
超大文件的行读取没有银弹。关键不是选哪个函数，而是想清楚：是一次性读、还是多次随机读、还是流式处理。选错方案，linecache 反而成为性能杀手。
