直接 open().read() 会爆内存，因为其默认将整个文件一次性加载进内存，当文件远大于可用 ram（如 50gb 日志在 16gb 内存机器上）时触发 memoryerror 或被 oom killer 杀死。
为什么直接 open().read() 会爆内存？
因为 Python 的 read() 默认把整个文件加载进内存，哪怕只是读几 GB 的纯文本，也会触发 MemoryError。尤其当文件远大于可用 RAM（比如 16GB 内存却要处理 50GB 日志），进程会被系统 OOM killer 杀掉——不是代码错，是设计没避开内存墙。
关键不是“能不能读”，而是“要不要一次性全读”。绝大多数文本处理任务（统计、过滤、逐行解析）根本不需要整块载入。
readlines() 和 for line in file 哪个更省内存？
for line in file 更安全。它底层用缓冲迭代器，每次只预读少量数据（通常 8KB 左右），内存占用基本恒定；而 readlines() 仍会把所有行对象塞进一个 list，每行字符串额外有引用开销，实际内存可能比原文件大 2–3 倍。
- ✅ 推荐写法：
with open('huge.log', 'r', encoding='utf-8') as f:<br> for line in f:<br> process(line) - ❌ 避免：
f.readlines()或list(f)，尤其在不确定行数时 - ⚠️ 注意：如果行特别长（比如单行 100MB JSON），
for line in f依然会卡住——这时得切物理块
如何按固定字节数分块读取并避免截断 UTF-8 字符？
用 read(size) 按字节读最直接，但 UTF-8 多字节字符可能被劈开，导致 UnicodeDecodeError。不能简单丢弃末尾字节，得回退到最近的合法 UTF-8 起始位置。
实操建议：
- 用
io.TextIOWrapper+buffer层手动控制：先raw = open(..., 'rb')，再用io.TextIOWrapper(raw, encoding='utf-8', errors='replace')，它内部会自动处理边界 - 或手动校验：读完一块后，检查末尾字节是否属于 UTF-8 多字节序列（如以
0xC0–0xFF开头），如果是，往回退 1–3 字节，再用decode('utf-8', errors='ignore')安全解码 - 常见坑：
encoding='utf-8-sig'仅去 BOM，不解决分块截断；errors='ignore'会丢数据，'replace'更稳妥
需要随机访问某一行时，怎么避免重复扫描？
纯流式读取无法跳转，但可以建轻量索引：第一次遍历记录每行起始偏移（file.tell() 在每次 readline() 后调用），存成 list 或 mmap 到磁盘。后续访问第 N 行，file.seek(offsets[n]) 再 readline() 即可。
注意点：
- 偏移量只对固定编码（如 UTF-8）可靠；换编码或含 BOM 时需重新计算 索引本身也占内存——10 亿行约需 8GB（每个 offset 是 64 位整数），不如用
- 真正海量场景（TB 级），考虑用外部工具预处理：用
split -l 1000000 huge.txt chunk_拆文件，再并行处理各 chunk
linecache 缓存热行
分块的本质是时间换空间，但选错策略会让 IO 成瓶颈。真正难的不是读，是确保每块解码正确、边界不丢失、状态可延续——比如解析 CSV 或嵌套 JSON 时，还得跨块拼接 token。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
