用'ab'模式追加写入断点续传的核心是：不覆盖原内容、自动定位eof、适配任意字节流；需配合range请求、206状态码校验及流式下载，避免oom与文件损坏。
用 open() 的 'ab' 模式追加写入
断点续传写入的核心是：不覆盖已有内容，从文件末尾继续写。Python 中最直接的方式就是用 open() 以二进制追加模式打开文件——'ab'。它会自动将文件指针定位到末尾，且不会清空原文件。
注意不要用 'a'（文本模式），尤其在处理非 UTF-8 编码或二进制数据（如下载的 zip、mp4）时，'a' 可能因换行符转换或编码问题导致写入错位或报错。
-
'ab'安全适用于任意字节流，包括网络响应体、加密数据、图片等 - 若文件不存在，
'ab'会自动创建；若存在，直接追加，不校验内容完整性 - 写入前无需手动调用
seek()，系统已定位到 EOF
写入前检查文件大小并校验服务端范围
单纯追加还不够——得确认服务端支持断点续传（即返回 Accept-Ranges: bytes），且本地已写入的字节数与服务端期望的起始偏移一致。否则可能重复写、跳字节或触发 416 Range Not Satisfiable。
典型流程是：先 HEAD 请求获取 Content-Length 和 Accept-Ranges；再检查本地文件大小 os.path.getsize(path)；最后发起带 Range: bytes=<code>start- 的 GET 请求。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
-
start = os.path.getsize(path)是关键起点，不是凭空猜的 - 如果服务端不支持
Range，requests会返回 200 全量响应，此时应删除本地残缺文件重下 - 务必检查响应状态码：
r.status_code == 206才表示成功接受断点请求
用 requests 流式下载 + shutil.copyfileobj() 避免内存膨胀
大文件下载中，把整个响应体读进内存再写（如 r.content）极易 OOM。正确做法是流式读取、分块写入，同时保持连接复用和异常可恢复性。
shutil.copyfileobj() 是标准库中专为流复制设计的函数，底层用小缓冲区循环读写，稳定且内存友好。
- 必须配合
stream=True初始化requests.get() - 打开本地文件时仍用
'ab'，不要用'wb'覆盖 - 示例关键片段：
with open(path, 'ab') as f: shutil.copyfileobj(r.raw, f) - 若中途出错（如网络中断），已写入的字节保留，下次从同一偏移继续
写入后校验 Content-Length 或 ETag 不够可靠
很多人以为下载完比对服务端 Content-Length 就算校验完成，其实有陷阱：HTTP 分块传输、压缩（gzip）、CDN 缓存都可能导致响应体长度与原始资源不一致。
ETag 也未必可用——有些 CDN 返回弱 ETag（W/"..."），或服务端根本没配。真正健壮的做法是：下载完成后，用服务端提供的 Content-MD5（如有），或主动请求完整资源的哈希（如通过 API 获取 SHA256），再本地计算校验。
- 本地校验必须基于最终写入的完整文件，而不是临时缓存或内存 buffer
- 若无服务端哈希，至少应确保
os.path.getsize(path) == expected_total_size，这是最基本防线 - 别在写入过程中频繁
os.stat()，会影响性能；校验只做一次，放在下载完成后的 final check 阶段
Content-Length。这些边界情况不会抛出明显异常，但会导致文件损坏且难以排查。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
