17370845950

断点续爬需设计含“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" 的记录——它们大概率是上次异常中断留下的。

• 用 SELECT url FROM urls WHERE status = 'pending' OR (status = 'processing' AND timestamp ，其中 ? 是当前时间减 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 层更细的语义。