断点续爬需设计含“pending/processing/done”三态、URL唯一键、时间戳与重试次数的状态结构，用SQLite事务保障原子更新，并在恢复时过滤超时的processing任务。
断点续爬不是加个文件写入就能用，关键在「状态定义是否覆盖全部失败路径」和「恢复时能否跳过已成功请求」。
如何设计可恢复的爬取状态结构
状态不能只记“当前页码”，要区分「待处理」「处理中」「已完成」三类标识，否则网络超时后重试会重复抓取或漏页。
-
url必须作为唯一键，避免因分页参数变动（如page=2和offset=20）导致状态错位 - 记录
status字段：值为"pending"、"processing"或"done"，不要用布尔值 - 必须保存
timestamp和retry_count，便于识别僵尸任务（如卡在processing超过 1 小时） - 建议用 SQLite 替代 JSON 文件——并发写入时不会因读写竞争丢失状态
用 SQLite 实现原子化状态更新
每次请求前先将目标 URL 状态设为 "processing"，成功后再改为 "done"。这一步必须用事务包裹，否则崩溃后状态永远卡住。
import sqlite3
conn = sqlite3.connect("crawl_state.db")
conn.execute("CREATE TABLE IF NOT EXISTS urls (url TEXT PRIMARY KEY, status TEXT, timestamp REAL, retry_count INTEGER DEFAULT 0)")
def mark_processing(url):
conn.execute("INSERT OR REPLACE INTO urls (url, status, timestamp) VALUES (?, 'processing', ?)", (url, time.time()))
conn.commit()
def mark_done(url):
conn.execute("UPDATE urls SET status='done', timestamp=? WHERE url=?", (time.time(), url))
conn.commit()
恢复时如何安全跳过已完成任务
启动时不能简单查 status != "done" 就开始跑，得额外过滤掉长时间处于 "processing" 的记录——它们大概率是上次异常中断留下的。
立即学习“Python免费学习笔记（深入）”；
- 用
SELECT url FROM urls WHERE status = 'pending' OR (status = 'processing' AND timestamp ，其中 <code>?是当前时间减 3600 秒 - 对每个恢复出的 URL，先检查本地是否已有对应响应缓存（如以
hash(url).hex() + '.html'命名的文件），有则直接标记"done"，避免重复请求 - 不要在恢复阶段批量 UPDATE 所有 pending 为 processing——高并发下易引发冲突，应逐条取、逐条标
requests + BeautifulSoup 场景下的典型陷阱
很多人把 response.text 直接存进数据库当缓存，结果遇到编码异常或 JS 渲染页就失效。状态恢复必须和实际数据落地解耦。
- 状态表只管 URL 生命周期，HTML 内容另存为独立文件，路径用
os.path.join(cache_dir, hashlib.md5(url.encode()).hexdigest()[:8] + '.html') - 如果解析逻辑抛出
AttributeError（比如soup.select(".title")返回空列表），不能回滚状态——这是业务逻辑错误，不是网络失败，应标记"done"并记录 error_type 到扩展字段 - 使用
requests.Session()时，别把 cookies 当状态保存——它们会过期；真正要持久化的只有 URL、重试次数、最后成功响应的 HTTP 状态码
最常被忽略的是「完成判定边界」：HTTP 200 不等于页面解析成功，而解析失败也不该反复重试同一 URL。状态字段必须承载比 HTTP 层更细的语义。
