status_code 不是判断抓取成功的唯一标准，因为200响应可能返回反爬页、空白html、js占位符或cdn错误模板；需同时满足状态正常、内容可解析、关键字段存在。
为什么 status_code 不是判断抓取成功的唯一标准
很多爬虫日志里看到大量 200 就以为数据抓到了，其实页面可能返回了反爬提示页、空白 HTML、JS 渲染占位符，甚至 CDN 缓存的错误模板。真正有效的响应必须同时满足：HTTP 状态正常 + 实际内容可解析 + 关键字段存在。
- 检查
Content-Type响应头是否为text/html或application/json，避免把图片或 404 页面当正文处理 - 对 HTML 响应，用
lxml或BeautifulSoup尝试解析，捕获ParserError或空title标签 - 对 JSON 接口，先用
json.loads()解析，再验证关键 key（如"data"、"items"）是否存在且非空 - 记录
response.elapsed.total_seconds()，超时（如 >15s）即使状态码是 200 也应归为“低质量响应”
如何从日志中识别高频但无效的请求模式
日志里反复出现的 URL 并不意味着重要，反而可能是反爬陷阱入口或分页逻辑缺陷导致的死循环。重点看 request.url 和 response.url 是否一致，以及重定向链长度。
- 提取所有含
?page=、&offset=的 URL，统计相同参数值重复出现次数，超过 3 次即标记为可疑 - 用正则匹配
response.headers.get("Location")或response.history长度，>2 跳的请求大概率被重定向到登录页或风控页 - 对比
request.url和response.url的域名与路径层级，若后者变成https://example.com/antibot/或/captcha，说明已触发防御 - 对 User-Agent 频繁切换但响应内容高度相似（如 MD5 值重复）的请求组，基本可判定为无效轮询
logging 模块怎么记录才能支撑后续质量分析
默认的 basicConfig 只记时间+级别+消息，无法做维度下钻。必须在 LogRecord 中注入结构化字段，方便用 Pandas 或 ES 聚合。
import logging
import json
<p>class RequestFilter(logging.Filter):
def filter(self, record):
if hasattr(record, 'url') and hasattr(record, 'status_code'):
record.log_json = json.dumps({
"url": record.url,
"status_code": record.status_code,
"elapsed": getattr(record, "elapsed", 0),
"size": getattr(record, "size", 0),
"error_type": getattr(record, "error_type", "")
}, ensure_ascii=False)
return True</p><p>logger = logging.getLogger("crawler")
handler = logging.FileHandler("crawl.log")
handler.setFormatter(logging.Formatter("%(log_json)s"))
handler.addFilter(RequestFilter())
logger.addHandler(handler)</p>- 务必把
url、status_code、elapsed、size作为日志属性传入，而不是拼在 message 字符串里 - 避免在
message中写动态内容（如f"failed on {url}"），会导致日志无法结构化解析 - 对异常捕获，用
logger.error("parse failed", exc_info=True, extra={"url": url, "status_code": 200})
用 Pandas 快速计算抓取质量核心指标
原始日志转成 DataFrame 后，几个关键指标能立刻暴露问题环节，不需要等完整跑完再复盘。
立即学习“Python免费学习笔记（深入）”；
import pandas as pd
import json
<p>df = pd.read_json("crawl.log", lines=True)
df["ts"] = pd.to_datetime(df["timestamp"])
df["is_2xx"] = df["status_code"].between(200, 299)
df["is_content_ok"] = (df["size"] > 1024) & (df["elapsed"] < 15.0)</p><h1>每小时成功率（2xx 且内容有效）</h1><p>hourly_success = df.groupby(df["ts"].dt.floor("H")).agg(
total=("status_code", "count"),
success=("is_content_ok", "sum")
).assign(rate=lambda x: x["success"] / x["total"]).round(3)</p><h1>高延迟 URL TOP 10</h1><p>slow_urls = df.nlargest(10, "elapsed")[["url", "elapsed", "status_code"]]</p>-
size小于 1KB 且状态码为 200 的响应，90% 是反爬页或骨架屏，直接剔除出有效样本 - 按
url分组统计status_code分布，若某 URL 固定返回 200+空内容，说明该入口已失效，应加入黑名单 - 注意
lines=True参数，否则read_json会因每行一个 JSON 对象而报错ValueError: Trailing data
真实场景里最常被忽略的是响应体语义一致性——比如同一批商品列表接口，有的返回 {"list": [...]}，有的返回 {"data": {"list": [...]}}，日志里都算 200，但解析代码只适配一种结构。这种差异不会体现在 status 或 size 上，只能靠抽样校验 response body schema。
