Python爬虫数据校验流程_保证数据准确性技巧【技巧】_技术教程

推荐用 Schema 显式校验数据结构，结合正则提取+范围检查处理动态字段，用 Session 复用连接并校验 HTTP 状态码与 content-type，再通过业务逻辑交叉验证关键字段一致性。

用 `assert` 和 `schema` 做结构化校验

爬虫拿到的 HTML 或 JSON 数据常有字段缺失、类型错乱、嵌套层级异常等问题。光靠 try/except 捕获 KeyError 或 TypeError 不够——它不告诉你“哪里该有但没出现”，只报错后中断。推荐在解析后立刻做显式校验：

from marshmallow import Schema, fields, ValidationError
class ProductSchema(Schema):
title = fields.Str(required=True)
price = fields.Float(required=True, validate=lambda x: x > 0)
sku = fields.Str(required=True, allow_none=False)
schema = ProductSchema()
try:
data = schema.load(raw_dict)
except ValidationError as e:
print("校验失败:", e.messages)  # 明确指出哪个字段缺了、哪个值不合法

比手写一堆 if not data.get("price") 更可靠，也更容易维护字段规则。

对动态字段做容错提取 + 范围检查

电商页价格可能写作 "¥199"、"199.00元"、"促销价：299"，直接 float() 会崩。不能依赖正则一把梭，得拆成两步：

先用保守正则提取数字片段（如 r"[\d.]+(?=\s*[¥元])"），匹配不到就 fallback 到空字符串
再对提取结果做数值合理性判断：比如价格超过 100000 或小于 0.1 就标为异常，不入库
记录原始文本和提取值，便于后续人工抽检

别让脏数据流进下游清洗环节——越晚发现，修正成本越高。

用 `requests.Session` 复用连接 + 校验 HTTP 状态码

很多爬虫忽略响应状态，以为 response.text 有内容就代表成功。实际可能返回 403（被反爬）、503（服务临时不可用）、甚至 200 套壳的“请开启 JavaScript”页面。必须显式检查：

import requests
session = requests.Session()
session.headers.update({"User-Agent": "Mozilla/5.0..."})
resp = session.get(url, timeout=10)
if resp.status_code != 200:
log.error(f"HTTP {resp.status_code} for {url}")
return None
if "text/html" not in resp.headers.get("content-type", ""):
log.warning(f"Unexpected content-type: {resp.headers.get('content-type')}")
return None
此时再 parse HTML

Session 还能自动管理 cookies 和复用 TCP 连接，减少超时和连接拒绝概率，间接提升数据获取稳定性。

关键字段交叉验证（比如时间+价格+库存逻辑一致性）

单字段校验只能防硬错误，但业务逻辑错误更隐蔽。例如抓到某商品 "on_sale": true，但 "sale_price" 等于 "original_price"，或 "stock" 是 0 却显示“立即抢购”。这类问题需写轻量级业务规则：

def validate_product_logic(data):
    if data.get("on_sale") and data["sale_price"] >= data["original_price"]:
        return False, "促销价不应高于或等于原价"
    if data.get("stock", 0) == 0 and data.get("status") == "in_stock":
        return False, "库存为0但状态显示有货"
    return True, ""
is_valid, reason = validate_product_logic(parsed_data)
if not is_valid:
log.warn(f"逻辑异常: {reason} | raw: {raw_html[:100]}...")

这种验证不追求全覆盖，但能快速揪出明显矛盾，比等报表跑出来才发现强得多。