如何在Python爬虫中监控目标网站内容变动并发送邮件报警？-Python教程-PHP中文网

核心是定期抓取关键内容片段并比对哈希值：用requests加headers获取页面，BeautifulSoup定位唯一DOM节点提取文本，标准化后生成MD5摘要存本地，下次运行时比对新旧hash，不一致即判定变动并邮件报警。

如何在python爬虫中监控目标网站内容变动并发送邮件报警？

用 `requests` + `BeautifulSoup` 抓取并比对页面内容是否变化

核心不是“实时监控”，而是“定期抓取 + 差异识别”。先确保能稳定获取目标页面的**关键内容片段**，比如某个

 里的文本，而不是整页 HTML（容易因广告、时间戳、埋点 JS 导致误报）。实操建议：

											
												
												
													Biopython
													全面的分子生物学工具集。适用于序列操作、文件解析（FASTA/GenBank/PDB）、系统发育分析，以及通过 Bio.Entrez 以编程方式访问 NCBI/
												
												下载
												
											
										

用 requests.get(url, timeout=10) 获取页面，加 headers 模拟浏览器（否则可能被 403）
用 BeautifulSoup(html, "lxml") 解析，定位到唯一性高的 DOM 节点，调用 .get_text() 提纯文本
对提取出的文本做标准化处理：去掉换行、多余空格、统一编码，再用 hashlib.md5(text.encode()).hexdigest() 生成摘要存本地（比如写进 last_hash.txt）
下次运行时读取旧 hash，和新 hash 对比，不一致即判定为内容变动

用 smtplib 发送纯文本邮件报警，绕过 Gmail 的 OAuth2 限制
很多教程卡在 Gmail SMTP 登录失败——因为 Gmail 默认禁用“低安全性应用访问”，且已逐步停用密码直连。最省事的解法是：不用 Gmail 账号，改用国内支持 SMTP 密码登录的邮箱（如网易 163 邮箱），或启用 Gmail 的“应用专用密码”（需开启两步验证）。
实操建议：

163 邮箱配置示例：smtp.163.com 端口 465，发件人填 yourname@163.com，密码填网页版邮箱设置里生成的“授权码”（非登录密码）
代码中用 smtplib.SMTP_SSL(host, port) 连接，server.login(from_addr, password) 认证
邮件正文别用 HTML，用纯文本 + \n 换行，避免被当垃圾邮件；主题加前缀如 [ALERT] example.com content changed

发送前务必测试一次，确认收件箱能收到且不进垃圾箱

用 schedule 或系统 cron 实现定时运行，避免用 time.sleep() 长驻进程
爬虫脚本不该常驻内存跑 while True: check(); time.sleep(300) —— 一旦异常退出就中断监控，还可能因网络卡顿导致重复执行或漏检。
实操建议：

推荐用系统级调度：Linux 下写一行 */5 * * * * cd /path/to && python3 monitor.py >> /var/log/monitor.log 2>&1 到 crontab -e，每 5 分钟拉起一次独立进程
若坚持用 Python 调度库，选 schedule（轻量）而非 APScheduler（重），并在主循环末尾加 schedule.run_pending(); time.sleep(1)，防止 CPU 占满
每次脚本启动时先检查上一次运行是否超时（比如读 last_run.pid 文件 + ps 查进程），避免多个实例并发冲突

内容变动误报的三个高频原因和应对方式
刚上线时最容易连续收到“内容已变”邮件，其实只是页面无关元素在抖动。
常见误报来源：

页面含实时更新的时间戳（如“最后更新：2024-06-12 14:23:01”）→ 用正则提前 re.sub(r"最后更新：\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}", "", text) 清洗
CDN 缓存不一致，A 地区看到新版，B 地区看到旧版 → 在请求头加 "Cache-Control": "no-cache"，并固定使用一个出口 IP（如走代理池中的某台）
JS 渲染内容（如 React 动态加载的正文）→ requests 拿不到，得换 playwright 或 selenium 启浏览器，但性能代价大，先确认目标站是否真依赖 JS

真正要监控的，永远是业务意义上“值得报警”的变化，比如政策页新增了 重要提示，而不是页脚版权年份从 2023 变 2024。