用 open() 配合 read(size) 分块读取大文件最直接高效，应使用 'rb' 模式、2 的幂 size（如 65536），避免按行读取和编码中断问题，必要时对 UTF-8 边界做安全回退处理。
用 open() 配合 read(size) 是最直接的分块读取方式
Python 默认的 open() 是缓冲 IO，但只要不调用 readlines() 或一次性 read()，就能避免把整个文件拖进内存。关键在控制每次读多少字节，而不是按行——因为超大 TXT 往往没换行或换行符不规律，按行容易卡死或 OOM。
实操建议：
- 始终用
mode='rb'打开，避免编码解析开销；解码留到后续处理块内（如需） -
size建议设为 8192、65536 等 2 的幂，对大多数文件系统更友好 - 不要用
for line in f:—— 它底层仍会预读缓冲区，且无法控制字节数 - 示例：
with open('huge.txt', 'rb') as f: while True: chunk = f.read(65536) if not chunk: break # 处理 chunk，比如写入临时文件或提取字段
遇到中文/UTF-8 编码断裂怎么办
按字节读时，很可能在多字节字符中间截断，比如 UTF-8 中一个汉字占 3 字节，read(65536) 刚好停在第 2 字节处，后续 .decode('utf-8') 就抛 UnicodeDecodeError: invalid continuation byte。
解决思路不是“全量读完再解码”，而是“安全回退 + 边界对齐”：
立即学习“Python免费学习笔记（深入）”；
- 每次读完先检查末尾是否为完整 UTF-8 序列：用
chuck[-3:].decode('utf-8', errors='ignore')看长度变化，或更准地用surrogateescape错误处理器保留原始字节 - 更稳妥的做法是：预留最后 1~3 字节不处理，和下一块拼接后再解码；或者用
io.TextIOWrapper包一层，但它会牺牲“精确字节控制”优势 - 如果业务允许，改用
codecs.iterdecode()+iter(lambda: f.read(65536), b'')组合，它内部会处理边界
mmap 适合只读、随机访问场景，但不省内存
有人看到“大文件”就想到 mmap，但它只是把文件映射成虚拟内存地址，并不减少 RSS 占用——操作系统仍可能把访问过的页加载进物理内存。真要压内存，mmap 反而更容易触发 swap。
适用条件很窄：
- 你需要频繁跳转读某几段（比如查索引表），而不是顺序扫一遍
- 文件在本地磁盘，且你信任 OS 的 page cache 策略
- 不用
mmap时已经确认read()调用本身成了瓶颈（少见） - 示例：
import mmap with open('huge.txt', 'rb') as f: with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) as mm: # mm[1000000:1000100] 直接切片取字节
别忽略 buffering 参数和系统页大小的影响
默认 open(..., buffering=-1) 会让 Python 选系统默认缓冲区（通常是 8KiB），但如果你手动设了 buffering=0（仅限二进制模式），就会禁用缓冲——每次 read() 都触发一次系统调用，I/O 次数暴增，速度反而暴跌。
还有两个隐形坑：
- Linux 下
read()实际最小单位是页大小（通常 4KiB），你设read(100)，内核仍可能读一页，只是 Python 只返回前 100 字节——剩余字节留在内核缓冲里，下次read()会先返回它们 - SSD/NVMe 对齐读取（如 4K 对齐）有性能优势，所以
size设为 4096 的倍数比设成 10000 更稳 - Windows 上
\?前缀可绕过路径长度限制，但和分块读无关，别乱加
实际跑起来你会发现：真正卡住的往往不是 Python，而是磁盘吞吐、编码校验、或者下游处理逻辑。字节分块只是第一关，后面每一步都得盯着 top 或 psutil.Process().memory_info().rss 看真实占用。
