python处理大日志文件应优先用for line in open()流式读取，避免readlines()导致oom；压缩日志用gzip.open(…, ‘rt’)并显式指定encoding；随机seek需字节安全，轮转场景须防inode失效。
用 open() + for line in file 就够了，别用 readlines()
Python 默认的文件迭代器是流式读取，内存只存一行，对 GB 级日志完全友好；readlines() 会把整个文件塞进内存，10GB 日志直接 OOM。这不是“推荐”，是底线。
常见错误现象：MemoryError 或进程被系统 kill，top 里看 Python 进程 RSS 瞬间飙到 20GB+。
- 永远避免
lines = f.readlines()或f.read().split('n') - 用
for line in open('access.log'):即可，不用手动close（CPython 中文件对象离开作用域会自动 close，但生产环境建议用with） - 如果需要跳过前 N 行（比如 header），用
itertools.islice(f, N, None)，比手动next()更安全
按块读取（read(size)）适合二进制处理或自定义分隔符
纯文本日志按行处理时，for line in file 已是最优；但如果你要提取固定长度的记录、跳过 bom、或解析非换行分隔的日志（如 json Lines 每行一个对象但内容含换行），就得切块读。
使用场景：日志是加密/压缩流、或每条记录以 x00 结尾而非 n。
立即学习“Python免费学习笔记（深入）”；
-
read(8192)是个稳妥起点，太小（如 1）触发频繁系统调用，太大（如 1MB）可能割裂单条日志（尤其当某行超长） - 注意：
read()不按行切，你得自己拼接缓冲区、识别行边界——容易漏掉跨块的换行符 - 除非真有特殊格式需求，否则别为“听起来更快”而切块；实测中，标准行迭代在 SSD 上已达磁盘吞吐瓶颈
gzip.open() 直接读压缩日志，但别套 io.TextIOWrapper
很多日志是 .log.gz，直接 gzip.open('app.log.gz', 'rt') 就能当普通文本文件用；加 io.TextIOWrapper 反而多一层 decode 开销，还可能破坏 encoding 参数行为。
常见错误现象：中文乱码、UnicodeDecodeError、性能反而下降 20%+
- 显式指定编码：
gzip.open('x.log.gz', 'rt', encoding='utf-8')，别依赖默认 - 不要写
io.TextIOWrapper(gzip.open(...), encoding='utf-8')——这是冗余包装，且TextIOWrapper的 buffer 策略和 gzip 内部 buffer 冲突 - 如果日志是
zstd或lz4，用对应第三方库（如zstandard），接口类似，但不支持内置open
用 seek() 跳转位置时，小心编码和行边界
想从文件末尾倒查最近 100 行？或者按时间戳二分查找？seek() 必须基于字节偏移，而 UTF-8 中一个汉字占 3 字节，seek(100) 可能停在某个字符中间，导致解码失败。
性能影响：随机 seek() 在机械硬盘上极慢，SSD 好些，但依然远不如顺序读。
- 用
file.tell()记录位置时，确保之前所有操作都是字节安全的（即没经过TextIOWrapper或没用encoding参数） - 倒序读行推荐
file.seek(0, 2)+ 往回找n，但必须用rb模式，自己处理解码——别指望seek()后直接readline() - 真正需要高频随机访问，考虑预建索引（如每 1MB 记录起始 offset），而不是每次现场 seek
最常被忽略的其实是日志轮转：程序运行中文件被 logrotate 重命名或清空，file.tell() 和当前 inode 就失效了；这类问题不会报错，只会静默丢数据。