requests.get()成功但页面内容为空，需先查日志确认请求是否被服务器正确接收并返回预期内容，重点检查URL编码、headers一致性、timeout设置及异常捕获。
为什么 requests.get() 成功但页面内容为空？先查日志再定位
爬虫看似运行成功，response.status_code 是 200，但 response.text 却是空字符串、跳转页或反爬提示页——这种“静默失败”最消耗排查时间。关键不是立刻改代码，而是确认请求是否真被目标服务器接收并返回了预期内容。
必须在发起请求前记录完整上下文：
-
url（注意是否含中文或特殊字符，需检查是否被自动编码） -
headers中的User-Agent、Cookie、Referer是否与浏览器一致 -
timeout值是否过小导致连接中断却未抛异常（requests默认无超时，建议显式设为timeout=(3, 7)） - 捕获
requests.exceptions.RequestException及其子类，而非只抓Exception
import logging
import requests
<p>logging.basicConfig(level=logging.INFO, format='%(asctime)s %(levelname)s %(message)s')
logger = logging.getLogger(<strong>name</strong>)</p><p>try:
resp = requests.get(url, headers=headers, timeout=(3, 7))
logger.info(f"GET {url} → {resp.status_code}, len={len(resp.content)}")
if not resp.content.strip():
logger.warning(f"Empty response from {url}")
except requests.exceptions.Timeout:
logger.error(f"Timeout on {url}")
except requests.exceptions.ConnectionError:
logger.error(f"Connection failed for {url}")</p>用 logging.Filter 精准过滤爬虫日志，避免告警疲劳
高频爬取时，每秒数条 INFO 日志会淹没真正的问题；而把所有 ERROR 都发邮件/钉钉，又容易因网络抖动触发误报。靠 logging.Filter 实现「只对特定错误模式告警」才是可持续方案。
例如：只对连续 3 次 503 Service Unavailable 或单次 429 Too Many Requests 触发告警，其余归档到文件即可。
立即学习“Python免费学习笔记（深入）”；
- 继承
logging.Filter，重写filter()方法，用实例变量缓存最近 N 次响应码 - 避免在 filter 中做耗时操作（如写数据库、发 HTTP 请求），否则阻塞主线程
- 将告警逻辑移出 filter，改为定时扫描日志文件或用
QueueHandler异步处理
class HttpStatusFilter(logging.Filter):
def __init__(self, name='', window_size=3):
super().__init__(name)
self.status_history = []
self.window_size = window_size
<pre class='brush:python;toolbar:false;'>def filter(self, record):
if hasattr(record, 'status_code'):
self.status_history.append(record.status_code)
self.status_history = self.status_history[-self.window_size:]
# 触发告警条件（不在此处发送，仅标记）
if record.status_code == 429 or self.status_history.count(503) >= 3:
record.needs_alert = True
return True监控 requests 耗时突增？用 timeit + 分位数比平均值更可靠
用 time.time() 差值统计单次请求耗时，再算平均值来判断“变慢”，会受偶发长尾请求干扰。比如 99% 的请求在 800ms 内完成，但某次 DNS 解析失败卡了 15s，平均值就被拉高，误判为服务退化。
真实可用的耗时监控应基于分位数（如 p95、p99）和突变检测：
- 用
time.perf_counter()替代time.time()，精度更高且不受系统时间调整影响 - 每分钟聚合一次耗时数据，计算
p95并与前一小时同时间段的p95对比，浮动超 200% 才触发告警 - 记录
connect和read阶段耗时（通过requests.adapters.HTTPAdapter的max_retries和自定义Response钩子）
import time
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
<p>class TimingHTTPAdapter(HTTPAdapter):
def send(self, request, <strong>kwargs):
start = time.perf_counter()
r = super().send(request, </strong>kwargs)
end = time.perf_counter()
r.elapsed_total = end - start
return r</p><p>session = requests.Session()
adapter = TimingHTTPAdapter()
session.mount("http://", adapter)
session.mount("https://", adapter)</p>钉钉/企业微信告警里别只写“爬虫异常”，要带可点击的上下文链接
收到告警消息后第一反应不是看日志，而是想：“这次是哪个任务？哪个 URL？哪台机器？” 如果告警正文只有 ERROR: Failed to parse JSON，就得翻日志、查进程、对时间戳——延迟 5 分钟以上才能定位。
真正的可运维告警必须自带诊断入口：
- 附上 Grafana 监控面板链接，带预设时间范围（如 ?from=now-15m&to=now）
- 包含本次失败任务的唯一 ID（如
task_id=spider_news_20240612_abc123），用于快速检索 ELK 日志 - 如果使用 Docker，带上
container_id和host_ip，方便直接docker exec -it进去查 - 避免在告警中放敏感信息（如 Cookie、token），可用哈希摘要替代原始值
最常被忽略的一点：告警恢复通知同样重要。没有它，你永远不确定上次报错是否已真实解决，还是被人工屏蔽了。
