直接用文件记录最后爬取ID会出错，因异常中断导致文件损坏或并发覆盖；应采用原子写法（如临时文件+os.replace）、加异常处理、多进程时改用SQLite/Redis。
为什么直接用文件记录最后爬取ID会出错
很多人用一个纯文本文件存上次爬到的 last_id，程序启动时读它、结束时覆盖写。这在单次正常退出时没问题，但一旦被 Ctrl+C、进程被 kill -9 或 Python 解释器崩溃，写入就中断了——文件可能变成空或只写了一半，下次读出来就是 ValueError: invalid literal for int() 或直接 FileNotFoundError。
更隐蔽的问题是并发场景：如果多个爬虫实例共用同一个记录文件，没加锁就会相互覆盖，last_id 值不可信。
实操建议：
- 改用原子写法：先写临时文件（如
progress.tmp），再os.replace()替换原文件，确保要么全写成功，要么原文件不受影响 - 读取时加
try/except包裹，失败就回退到默认起点（比如0或1），别让整个任务卡死 - 若需多进程安全，改用 SQLite（自带 WAL 模式和行级锁）或 Redis，避免文件竞争
requests + BeautifulSoup 场景下如何安全保存断点
这类轻量爬虫通常按页码或 ID 顺序请求，断点本质是「当前处理到哪一页/哪个ID」。关键不是存得快，而是存得稳——尤其在 for page in range(1, 1000) 这种循环里，不能等到整页解析完才更新进度，否则某条数据解析异常导致页面跳过，进度就永远落后了。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 在每次成功获取并解析完一页后，立刻更新进度（比如写入
progress.json），而不是在循环末尾统一写 - 把进度写入和业务逻辑解耦：封装成独立函数
save_checkpoint(page_num, url)，内部处理异常和重试 - 示例中避免用
json.dump()直接覆写，改用tempfile.NamedTemporaryFile(delete=False)+shutil.move()保证原子性
Scrapy 中启用内置断点续爬的正确姿势
Scrapy 自带 JOBDIR 设置，但它不是“记住最后爬到哪”，而是持久化整个调度队列和去重指纹。很多人开了 JOBDIR=./jobdir 却发现重启后还是从头爬——因为默认 DUPEFILTER_CLASS 用的是内存版 RFPDupeFilter，jobdir 里的去重数据根本没生效。
实操建议：
- 必须显式指定去重类：
DUPEFILTER_CLASS = 'scrapy.dupefilters.RFPDupeFilter'（这是磁盘版，依赖 jobdir） -
JOBDIR路径要绝对且可写，相对路径在 daemon 模式下容易失效；建议初始化时用os.path.abspath("jobdir") - 不要手动删
jobdir下的requests.queue，那是二进制队列文件，删了 Scrapy 就认为任务已完成，直接退出 - 想从特定 URL 续爬？用
scrapy crawl myspider -s JOBDIR=./jobdir -a start_urls='["https://..."]'，并在start_requests()中判断是否已有 jobdir
遇到 ConnectionResetError 或 503 时怎么不丢进度
网络抖动导致请求失败很常见，但很多人把重试逻辑和进度更新混在一起：失败就跳过该请求，结果这个 URL 永远不会被重试，进度却已推进——相当于漏爬。
实操建议：
- 对临时性错误（
ConnectionResetError、Timeout、HTTP 503/504），别更新进度，直接raise scrapy.exceptions.IgnoreRequest（Scrapy）或continue（requests 循环），让同一请求稍后重试 - 对永久性错误（404、410、解析失败超 3 次），才调用
save_checkpoint()并跳过 - 在中间件或装饰器里统一捕获异常，避免每个
yield Request(...)后都写重复逻辑
真正难的不是写几行保存代码，而是想清楚「什么算成功」：是响应返回？是状态码 200？是 HTML 里有目标字段？还是数据已入库？每层定义不同，断点位置就该不同。别让进度文件成了新的单点故障源。
