断点续传的核心是保存和恢复文件读取位置，需手动记录file.tell()偏移量并用file.seek(offset)恢复，必须在每次成功处理后立即落盘至原子更新的.offset文件，且全程使用'rb'模式确保字节级准确。
断点续传的核心是保存和恢复文件读取位置
Python 本身没有内置“断点续传”概念，它只是靠手动记录上次读到的 file.tell() 偏移量，下次用 file.seek(offset) 接着读。关键不在于“传输”，而在于你如何持久化这个偏移量、何时保存、以及怎么应对崩溃或中断。
常见错误是：只在读完一批数据后才写偏移量，结果中途崩溃就丢进度；或者把偏移量存在内存里，程序退出就清零。
- 偏移量必须在每次成功处理完一块数据后立即落盘（比如写入一个
.offset文件） - 读取前先尝试读
offset_file，若存在且内容是合法整数，就用它做seek()起点 - 注意文本模式和二进制模式下
tell()返回值语义不同：文本模式受换行符转换影响，偏移量可能不连续；务必用open(..., 'rb')
用 shelve 或纯文本存偏移量各有什么坑
存偏移量最轻量的方式就是写个纯文本文件，比如 data.bin.offset 里只放一行数字。简单可靠，但要注意写入原子性——直接 f.write(str(pos)) 可能写一半崩溃，导致文件损坏。
shelve 看似高级，但它底层依赖 dbm，在并发或异常退出时容易损坏数据库文件，且不支持跨平台字节序兼容。对单进程断点续传属于杀鸡用牛刀，还多一层风险。
立即学习“Python免费学习笔记（深入）”；
- 推荐做法：写新临时文件（如
data.bin.offset.tmp），os.replace()原子替换原 offset 文件 - 读 offset 时加
try/except ValueError，防止文件为空或含非法字符 - 不要用
shelve存单个整数——序列化开销大，出错难调试
分块读取时如何避免重复或跳过数据
偏移量本身只是字节位置，真正决定“哪块数据已处理”的是你分块逻辑。典型错误是：用固定 chunk_size=8192，但没校验最后一次读是否真读满，导致最后一块被漏掉或重复处理。
例如：文件总长 10000 字节，chunk_size=8192，第一次读 0–8191，第二次 seek(8192) 后 read(8192) 实际只返回 1808 字节。如果你只靠 len(chunk) == chunk_size 判断是否结束，就会误判。
- 正确做法：以
chunk = f.read(chunk_size)是否为空字符串（b''）为 EOF 标志 - 每次成功处理完
chunk后，更新 offset =f.tell()（不是offset + len(chunk)，因为tell()更准确） - 如果处理逻辑可能失败（如解析 JSON 失败），必须在成功提交后才更新 offset，否则会跳过出错那块
Windows 下 seek() 和 tell() 的兼容性问题
在 Windows 上用文本模式打开二进制文件（比如 CSV、日志），tell() 返回值可能和实际字节数不一致，因为 CRLF 换行符会被当作一个字符处理，但占两个字节。这会导致你用 tell() 记下的位置，在下次 seek() 时错位。
即使你只是读纯 ASCII 数据，只要用了 open(..., 'r')，就可能中招。这不是 bug，是 Python 文本模式的规范行为。
- 唯一稳妥解法：所有断点续传场景一律用
open(..., 'rb')和open(..., 'wb') - 如果原始数据是文本（如 JSON 行），读出来再用
chunk.decode('utf-8')解码，别让 open 自己处理编码 - 测试时可在 Windows 上用
xxd data.bin | head对照tell()值，确认是否对齐
偏移量本身不复杂，难的是在各种异常路径下保证它和业务处理状态严格一致——比如网络上传失败、磁盘满、Ctrl+C 中断，这些时刻 offset 文件是否已更新、是否与内存状态冲突，才是真实痛点。
