requests.get()返回关键字段为空主因是页面动态渲染、反爬跳转或未判空处理；需校验状态码、Content-Type、跳转URL，并对字段做语义化校验与分层补爬。
为什么 requests.get() 返回的页面里关键字段总是空？
多数缺失不是网络失败导致的，而是目标页面结构动态变化、反爬策略触发（返回了跳转页或验证码页）、或 JS 渲染内容未被静态请求捕获。直接用 requests + BeautifulSoup 解析时，select() 或 find() 返回 None 却没做判断，数据就静默丢失了。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 所有关键字段提取必须包裹在
try/except或显式判空逻辑中，例如：title_elem = soup.select_one('h1.title'); title = title_elem.get_text(strip=True) if title_elem else None - 对每个响应，先检查
response.status_code是否为200，再检查'text/html' in response.headers.get('content-type', '')，避免把 JSON 错当 HTML 解析 - 记录原始
response.url，比对是否发生 302 跳转（比如跳到登录页），这类跳转常导致字段批量为空
怎么设计可落地的数据校验规则？
校验不是“有没有值”，而是“值是否符合业务语义”。比如商品价格字段是空字符串、'暂无报价'、还是 None，修复方式完全不同。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 定义字段级校验函数，例如：
def validate_price(v): return isinstance(v, (int, float)) and v > 0，而不是只写if not price: - 对必填字段（如 ID、标题）设置硬性校验，失败时打日志并标记为
status='missing_required'；对非必填字段（如副标题、标签）允许为空，但记录缺失率用于后续分析 - 用
dataclasses或 Pydantic 模型封装数据结构，在__post_init__或validator中集中校验，避免散落在各处的if判断
补爬逻辑该不该重试整个页面？
盲目重试整个页面效率低，还可能触发风控。更合理的是识别出“可补救的缺失”——比如图片 URL 抓错了但详情页还在，或某个 API 接口临时 502，而其他字段已成功获取。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 将抓取流程拆成原子步骤：基础信息（标题、ID）→ 扩展字段（价格、库存）→ 多媒体（图片、视频），每步独立记录状态和错误类型
- 对扩展字段缺失，优先调用备用接口（如从商品 ID 拼接另一个 API 地址），而不是重新请求主页面
- 补爬任务进队列前加去重和限频：用
(url, field_name)作唯一键，且同域名补爬间隔 ≥ 2 秒，避免被识别为异常行为
如何避免补爬变成无限循环？
常见陷阱是“补爬失败 → 再补爬 → 再失败”，尤其当目标页面结构已永久变更，或字段彻底下线时。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每条数据最多补爬 2 次，第二次失败后写入
failed_reason='retried_twice'并停止，人工抽检样本再决定是否调整解析逻辑 - 补爬任务带时间戳和来源标记（如
source='retry_price_from_api_v2'），方便查问题时不混淆原始抓取和补爬结果 - 监控缺失率突增：如果某类字段连续 1 小时缺失率 > 80%，自动告警而非继续补爬——大概率是页面改版了
真正难的不是写补爬代码，而是区分哪些缺失能靠重试解决，哪些必须重构选择器或切换数据源。上线前拿 50 条真实失败样本跑一遍校验+补爬链路，比看十遍文档都管用。
