在操作大文件时，seek() 方法经常出现失效或定位不准的情况，这背后有一个根本原因：文本模式是按字符读取的，而 seek() 却是按字节来跳转的。在 UTF-8 编码下，一个中文汉字、emoji 表情等字符可能占用 2 到 4 个字节，直接使用 seek(100) 很容易跳到某个汉字的中间位置，导致后续 readline() 抛出 UnicodeDecodeError 异常，或者返回一堆乱码。
为什么 seek() 在大文件里经常失效或不准？
问题的核心在于字符与字节之间的换算差异。文本文件默认按字符进行操作，而 seek() 则是基于字节位置来定位的。在 UTF-8 编码中，一个汉字通常占用 2 到 4 个字节，如果直接跳转到某个字节编号，很可能落在字符内部的中间位置，从而引发解码错误。
- 使用二进制模式（
'rb'）才是安全调用seek()的正确方式：跳转时只关心字节位置，不涉及任何编码解析。 - 在文本模式（
'r'）下，seek()只能跳转到0或之前tell()返回的位置——简单来说，只能回到已经读取过的位置。 - 如果希望“随机读取某一行”，不能靠
seek(N)猜测位置，而是需要先建立索引，例如记录每一行的起始字节偏移量。
如何用 seek() 安全跳转到指定字节位置并读取？
这个方法特别适用于日志分析、二进制数据提取等场景，前提是你明确知道目标位置是一个合法的字节边界——比如固定长度的记录，或者已知结构的文件头部。
- 必须使用
open(..., 'rb')模式打开文件。 f.seek(offset, whence=0)：whence=0表示从文件开头计算偏移量，1表示从当前位置，2表示从末尾（注意：seek(-10, 2)表示倒数第 10 个字节）。- 跳转完成后，使用
f.read(n)读取指定字节数，再按需解码，比如data.decode('utf-8', errors='ignore')。
with open('large.log', 'rb') as f: f.seek(1024 * 1024) # 跳到 1MB 处 chunk = f.read(1024) # 读 1KB text = chunk.decode('utf-8', errors='replace')如何实现“随机读第 N 行”而不加载全文？
核心思路是预先构建行偏移索引——遍历一次文件，记录每一行开头的字节位置。之后每次需要读取第 N 行时，只需 seek() 到该位置，再调用 readline() 即可。
- 索引可以保存为
.idx文件，或者放在内存列表中；只要文件内容不变，建立一次索引就能长期复用。 - 构建索引时务必使用
'rb'模式，逐字节查找b'n'，这样能避免编码问题。 - 第 0 行对应索引
offsets[0]，第 N 行使用f.seek(offsets[N])，然后f.readline()读取。
# 构建索引（一次）offsets = [0]with open('big.txt', 'rb') as f: while f.readline(): offsets.append(f.tell())# 随机读第 100 行with open('big.txt', 'rb') as f: f.seek(offsets[100]) line = f.readline().decode('utf-8', errors='ignore')用 mmap 替代 seek() 会更高效吗？
对于 GB 级别以上的超大文件，mmap 能够减少频繁的系统调用，在随机访问固定偏移区域时表现更优。但它并不能解决“按行读取”的语义问题。
mmap是内存映射机制，seek()则是文件指针移动——两者原理不同，不能混为一谈。- 使用
mmap后可以直接通过切片访问：mm[1000:1024]，比seek()+read()少一次 I/O 操作。 - 注意：
mmap会占用虚拟内存，使用完毕后必须调用mm.close()释放；在 Windows 系统下打开文件时，需要加上access=mmap.ACCESS_READ参数。
import mmapwith open('huge.bin', 'rb') as f: with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) as mm: chunk = mm[512*1024:512*1024+1024] # 直接切片读在实际运用 seek() 进行随机读取时，本质上是在与文件编码、行结构、I/O 缓冲机制进行博弈。最容易忽视的一点是：你可能以为自己跳到了“第 100 行的开头”，但实际上只是跳到了“字节位置 12345”，而那里可能是半个 UTF-8 字符，也可能是换行符的中间部分。
