网站资讯监控工具搭建实战：轮询抓取/指纹比对/推送告警

简介：网站资讯监控工具适合需要实时跟踪目标网站更新或特定关键词的动态内容，面向网站运营、资讯采集、舆情监测等场景。工具同时提供更新监控与关键字监控，可单独或组合使用，支持多网站并行监控，并针对每个网址单独设定监控方式；关键字可分组管理，配合十多种过滤方式减少无关信息干扰。监控到新内容后可通过声音、弹窗、邮件、免费短信及手机QQ提醒等方式即时报警，同时完整记录监控历史，便于随时回溯查阅。压缩包共4个文件，大小10.49MB，包含可执行的安装程序、企业版介绍页面、安装升级必读说明及文本说明文档，覆盖安装、配置和功能参考等环节。目前已有885人学习下载，适合需要快速部署网站更新监控、追求高性价比提醒方案的普通用户；若监控网址多、提醒频率高，资源内也提供了企业版功能对比供升级参考。

1. 网站资讯监控工具：先搞清楚它在解决什么问题

网站资讯监控工具，说到底干的是一件事：定时去看目标页面变没变，变了就告诉你。某个做运营的朋友曾经找我，说她们每天要刷新对家公告页好几遍，怕漏掉新版本发布，后来给页面加了每十分钟一次的监控脚本，才算把这件事自动化。这个方向适合三类人：盯竞品动态的运营、等官网更新文档的开发者、以及想第一时间拿到某类特定资讯的人。它不解决“爬全网数据”的问题，只解决“别让我错过关键更新”的问题。下面按定策略、写脚本、接推送、踩坑排查、进阶优化的顺序，把一套可复现的方案完整讲清楚。

2. 监控策略怎么选：轮询抓取、RSS 订阅还是第三方变更检测

做监控工具，第一步不是写代码，而是定策略。我见过不少人在选型上翻车：有人一开始就上了无头浏览器，结果内存占用高得吓人；也有人只靠 RSS，结果站点悄悄下架了 feed 半个月才发现。先花十分钟想清楚监控对象和更新频率，后面能省出一周的维护时间。下面把三种常用方案摆开对比，再给出我一般会怎么选。

2.1 三种监控方案对比：先看原理，再谈选型

这张表里最值得关注的是“可控性”这一列。自建轮询抓取前期要写的代码确实多一些，但监控频率、比对逻辑、通知渠道全都可以按需调整。RSS 在协议层面最优雅，可惜现在好多资讯站把 feed 关掉了；第三方服务最省事，却要接受目标页面数据先经过别人服务器这个前提。我在模拟项目X里最终选的是自建轮询，因为要盯的页面一共不到 20 个，频率要求每 10 分钟一次，这个量级用 requests 加一个定时任务就足够稳定。

2.2 自建轮询抓取的适用边界：什么时候选它，什么时候别选

自建轮询不是万能的，我一般用三条线来卡边界。第一条是规模，目标页面最好在 50 个以内，超过这个量级，单线程轮询的周期会明显拉长，某个页面超时还会拖累整轮任务；第二条是更新频率，如果页面每分钟都在变，轮询间隔就不得不压缩到秒级，这会成倍放大被封风险，这时候应该优先考虑接口推送或第三方服务；第三条是页面结构稳定性，目标站三天两头改版的话，抓取逻辑要跟着改，维护成本会吃掉所有收益。

反过来看，如果监控对象符合“页面少、更新不频繁、结构稳定”这三个特征，自建轮询就是性价比最高的方案。不需要额外安装服务，一台小机器甚至一台旧笔记本就能跑。早期版本先用最简单的方式把需求验证起来，等真的出现误报和漏报，再一步步把指纹算法和通知逻辑做厚。这也是我反复推荐先自建的原因：从零到跑通只需要一个下午，而第三方方案一旦用上，后续想拿回控制权就要重写一遍。

2.3 先给目标站点分类：静态 HTML、动态渲染还是接口直出

真正写抓取之前，先确认目标页面的形态。最常见的是三种情况：静态 HTML 页面，请求返回的响应里直接包含正文，用 requests 拿到 response.text 就能解析；动态渲染页面，HTML 里只有框架壳子，正文由 JavaScript 在浏览器里拼出来，直接抓只能得到空壳；接口直出，页面正文其实来自某个 XHR 请求，返回 JSON 或 HTML 片段，这类接口往往比页面本身更稳定。

判断方法很朴素：在命令行里跑一条 curl 把返回内容存成文件，然后搜索页面正文里某个有代表性的标题词。搜得到就是静态页面，搜不到基本可以断定是动态渲染，需要去 Network 面板里找真正的数据接口。

提示：别急着上无头浏览器。先花十分钟找接口，多数情况下接口方案比无头浏览器稳定得多，也省资源得多。

判断清楚页面类型之后，就可以动手写脚本了。核心链路是抓取、归一化、算指纹、存状态、比对，下一章给出的代码可以直接抄走改参数。

3. 用 Python 搭最小可用监控脚本：抓取、指纹比对与 SQLite 状态存储

策略定了就动手。下面这套组合是我在类似需求里反复用过的：requests 负责抓取，hashlib 负责算指纹，sqlite3 负责存历史状态。它不依赖重型框架，Python 标准库加一个 requests 就能跑起来，逻辑也足够透明，出问题的时候打开脚本一眼就能定位。

3.1 抓取目标页面：请求头、超时与状态码处理

import hashlib import re import sqlite3 import time import requests TARGET_URL = "https://example.com/news" HEADERS = { # 从你自己浏览器开发者工具里复制一份完整 UA，不要用短 UA "User-Agent": "your-browser-user-agent-here", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8", } def fetch_page(url: str) -> str: """抓取页面 HTML，失败时抛异常交给上层处理""" resp = requests.get(url, headers=HEADERS, timeout=10) resp.raise_for_status() return resp.text

这段代码里有三个参数值得注意。timeout=10 是必须的：没有超时的话，某个页面挂起会让整个监控任务卡死，定时任务里尤其致命。raise_for_status() 会在返回 4xx、5xx 时直接抛异常，避免把错误页当成正常内容存进快照。HEADERS 里的 User-Agent 是最容易被忽略的反爬因素，短 UA 很容易被服务端识别为脚本，后面第 5 章会专门展开。

3.2 内容指纹：先归一化，再算哈希

def normalize_html(html: str) -> str: """去掉注释、脚本、样式和多余空白，避免格式微调造成误报""" html = re.sub(r"<!--.*?-->", "", html, flags=re.S) html = re.sub(r"<(script|style)[^>]*>.*?</\1>", "", html, flags=re.S) html = re.sub(r"\s+", " ", html) return html.strip() def content_hash(html: str) -> str: """对归一化后的内容算 SHA-256，作为页面指纹""" return hashlib.sha256(normalize_html(html).encode("utf-8")).hexdigest()

为什么不直接对整个 HTML 算哈希？因为很多页面每次请求都会带上动态时间戳、埋点参数或者随机的广告位，直接算哈希会造成“内容没变但指纹总在变”的假警报。归一化的目的就是把这些噪音压掉：注释删掉、script 和 style 里的内容删掉、连续空白折叠成单个空格。正则里的 flags=re.S 让 . 能匹配换行，否则跨行的注释和脚本块会被漏掉；</\1>里的 \1 反向引用保证开始和结束标签名一致。

3.3 状态存储：用 SQLite 记住上次快照

DB_PATH = "snapshots.db" def init_db(db_path: str = DB_PATH) -> sqlite3.Connection: conn = sqlite3.connect(db_path) conn.execute( """ CREATE TABLE IF NOT EXISTS snapshots ( url TEXT PRIMARY KEY, content_hash TEXT NOT NULL, updated_at REAL NOT NULL ) """ ) conn.commit() return conn def save_snapshot(conn: sqlite3.Connection, url: str, digest: str) -> None: """写入或更新某个 URL 的指纹，url 作为主键""" conn.execute( """ INSERT INTO snapshots (url, content_hash, updated_at) VALUES (?, ?, ?) ON CONFLICT(url) DO UPDATE SET content_hash = excluded.content_hash, updated_at = excluded.updated_at """, (url, digest, time.time()), ) conn.commit()

SQLite 是这个场景下的合理选择：单文件、零配置、Python 标准库直接支持，不需要额外起服务。表结构里用 url 做主键，天然支持多页面监控，同一页面反复写入就走 UPSERT 更新指纹。updated_at 存 time.time() 的结果，也就是 Unix 时间戳，方便后续按时间维度排查。这里需要注意的是 ON CONFLICT 语法要求 SQLite 3.24.0 以上版本，大多数现代系统的 Python 自带的 SQLite 都满足，但如果你在很老的服务器上跑，需要先确认版本。

3.4 主流程：首次运行、发现变化、无变化三分支

def main() -> None: conn = init_db() html = fetch_page(TARGET_URL) digest = content_hash(html) row = conn.execute( "SELECT content_hash FROM snapshots WHERE url = ?", (TARGET_URL,) ).fetchone() if row is None: print("[首次运行] 记录初始快照，不发送通知") save_snapshot(conn, TARGET_URL, digest) elif row[0] != digest: print("[发现更新] 页面内容发生变化，进入通知流程") save_snapshot(conn, TARGET_URL, digest) # 第 4 章在这里接入推送 else: print("[无变化] 内容与上次一致，本轮结束") conn.close() if __name__ == "__main__": main()

首次运行不通知，这个设计一开始就要想清楚。如果部署当天就收到一条“内容变化”的提醒，大概率是首次快照和真实内容不一致造成的困惑，先把基线建立起来，之后再检测到的变化才是真正的新增内容。发现变化的顺序也有讲究：先把新快照存入数据库，再走通知流程，避免推送成功但快照没存上，导致同一变化被重复提醒。

到这里，一个能感知“页面变没变”的最小脚本已经完整了。下一步要解决的是“怎么让我知道”。

4. 把监控结果送到手机：Webhook 推送、告警去重与 crontab 调度

检测到变化之后，通知链条如果没打通，监控工具的价值就少了一半。最常见的做法是接 IM 群机器人的 Webhook：一条 POST 请求发过去，消息就出现在手机上了。相比邮件，Webhook 延迟低、配置简单，适合这种低频告警场景。

4.1 接入 IM 群机器人 Webhook：一条 POST 搞定推送

WEBHOOK_URL = "https://your-im.example.com/hook/your-token" def send_notification(title: str, content: str) -> None: """向群机器人发送文本消息，msgtype 和字段名按平台调整""" payload = { "msgtype": "text", "text": { "title": title, "content": content, }, } resp = requests.post(WEBHOOK_URL, json=payload, timeout=10) resp.raise_for_status()

不同 IM 平台的 webhook 字段名略有差异，有的用 content 包正文，有的用 markdown 类型，但思路完全一致：构造 JSON、POST 过去、检查返回状态。timeout=10 依然不能省，推送接口挂起会导致整个脚本卡住。raise_for_status() 同样重要，很多平台在频率超限或 token 失效时会返回 4xx，不检查的话，你以为通知发出去了，实际手机上一片安静。

多页面监控的改造也很自然：把 TARGET_URL 换成 PAGES 列表，循环抓取、比对、推送，每轮间隔可以用 time.sleep 控制，也可以完全交给定时任务。

PAGES = [ {"url": "https://example.com/news", "name": "资讯中心"}, {"url": "https://example.com/version", "name": "版本公告"}, ] for page in PAGES: digest = content_hash(fetch_page(page["url"])) # 比对逻辑与单页面一致 # 推送时把 page["name"] 拼进标题，手机上能直接看出是哪个页面变了

把页面名称拼进通知标题，是实操中特别值得坚持的习惯。否则同一个 Webhook 里跳出三五条“内容有更新”，你根本分不清是哪个站，还得打开电脑查日志。

4.2 告警去重与冷却时间：避免通知轰炸

页面内容变化不等于每条变化都值得打扰你。常见做法是加一个冷却时间：同一页面在设定间隔内只提醒一次，即使脚本每 10 分钟跑一轮，也不会把同一件事重复推送三遍。

import json import os STATE_FILE = "notify_state.json" COOL_DOWN_SECONDS = 1800 # 同一页面 30 分钟内最多提醒一次 def load_state() -> dict: if not os.path.exists(STATE_FILE): return {} with open(STATE_FILE, "r", encoding="utf-8") as f: return json.load(f) def save_state(state: dict) -> None: with open(STATE_FILE, "w", encoding="utf-8") as f: json.dump(state, f, ensure_ascii=False, indent=2) def should_notify(url: str) -> bool: """超过冷却时间才允许再次通知，否则忽略本次变化""" state = load_state() last_ts = state.get(url, 0) now = time.time() if now - last_ts < COOL_DOWN_SECONDS: return False state[url] = now save_state(state) return True

冷却时间用 JSON 文件存状态，好处是直观，坏了能直接打开看。COOL_DOWN_SECONDS 设多大取决于页面更新频率：资讯站可以设 300 秒，版本公告这类低频页面设 1800 秒以上更合适。这个机制解决的是“通知轰炸”问题，但不能替代指纹本身的降噪，两者配合使用才是完整方案。

4.3 定时调度：用 crontab 让监控每 10 分钟跑一次

脚本写好了，最后一步是让它自动跑起来。Linux 服务器上最朴素可靠的就是 crontab，一条规则解决调度问题。

# 每 10 分钟执行一次监控脚本，标准输出和错误都追加到日志 */10 * * * * cd /path/to/monitor && /usr/bin/python3 monitor.py >> monitor.log 2>&1

crontab 环境变量比交互式 shell 少，所以 python3 建议写绝对路径，用 which python3 查一下即可。cd 到项目目录再执行，保证脚本里相对路径的文件都能找到。>> monitor.log 2>&1 把输出和报错都写进日志，这一步是非凡关键的排障入口：通知没收到时，第一件事就是看这个文件里到底发生了什么。

5. 网站资讯监控的高频坑：反爬、编码、动态页面与通知轰炸

自建监控工具做到能跑通容易，做到长时间稳定运行难。下面这几个坑是我在类似项目里踩过、也帮别人排查过的，每一条都按“现象、原因、解决”写清楚，遇到类似问题直接对照处理。

5.1 请求返回 403：伪装不到位

现象：脚本部署第二天，某几个页面开始返回 403，或者返回一个“请验证身份”的中间页。原因是请求头暴露了脚本身份：User-Agent 太短、缺少 Accept-Language，或者单位时间内请求频率太高。

解决：先从自己浏览器复制完整 UA 填进 HEADERS，再把请求间隔拉长。如果监控的页面超过 10 个，不要在一个循环里连续抓完，中间加随机 sleep。还要注意一个原则：只监控公开页面，不要对需要登录或明确禁止抓取的页面做轮询，这不是技术问题，是边界问题。

5.2 乱码与错误正文：编码识别不可靠

现象：抓下来的标题和正文全是乱码，但浏览器里看完全正常。原因是 requests 默认按 HTTP 响应头里的 charset 解码，部分站点在响应头里没声明编码，或者声明得不对，导致解码用了错误的字符集。

解决：在拿到响应后显式修正编码。常见做法是判断响应头未声明编码时，用 apparent_encoding 做兜底。

resp = requests.get(url, headers=HEADERS, timeout=10) if resp.encoding is None or resp.encoding.lower() == "iso-8859-1": resp.encoding = resp.apparent_encoding html = resp.text

apparent_encoding 是 requests 基于内容自动检测的编码，对中文页面基本可靠。但要注意它对每个响应都会做额外分析，有自己的开销，所以只在没有显式编码时启用，而不是每次请求都跑。

5.3 页面没变但哈希总在变：动态渲染和埋点时间戳

现象：日志里频繁出现“发现更新”，但人眼看页面根本没变。原因是页面里混入了每次请求都不同的内容，最常见的是三类：JavaScript 渲染的动态区块、匿名的埋点时间戳、随机刷新的广告位。

解决：先重新检查 2.3 的页面分类。如果页面是纯静态的，问题就出在归一化不够，把 script、style、iframe 等易变区块在指纹计算前过滤掉。如果页面本身是动态渲染的，直接抓 HTML 这条路就要重新评估，优先去寻找页面背后的数据接口，用接口返回的内容做指纹，稳定性能提升一个量级。

5.4 通知轰炸：监控对象本身在持续小幅更新

现象：某个页面开始每隔一两个小时推送一次，推送内容都是无关紧要的小改动，比如在线人数、访问计数、推荐位顺序。

原因：指纹粒度太粗，把页面的“易变区块”也纳入了比对范围。解决方法是缩小指纹范围：只对页面主体区域的文本计算指纹，而不是对整页 HTML。

from bs4 import BeautifulSoup def body_text_fingerprint(html: str) -> str: """提取正文区域文本后计算指纹，过滤边栏、计数、广告等噪音""" soup = BeautifulSoup(html, "html.parser") main = soup.find("main") or soup.find("article") or soup.body text = main.get_text(" ", strip=True) return hashlib.sha256(text.encode("utf-8")).hexdigest()

选择正文容器的优先级是 main、article、body 逐级后退。用 get_text(" ", strip=True) 把正文里的标签全部去掉，只保留纯文本，这样页面侧边栏或页脚的小变动就不再影响指纹。这里的代价是丢失了页面里的链接结构，但对“资讯监控”这个场景，关注的就是文字内容变化，纯文本指纹反而更准确。

5.5 手机收不到通知：静默失败

现象：脚本日志显示检测到了变化，但手机上没有收到任何推送。原因通常是两类：一是抓取或推送过程里的异常被吞掉了，二是页面结构变化导致正文区域提取不到内容，指纹计算拿到了空文本。

解决：给脚本加上系统化日志，把每一次抓取、比对、推送的关键节点都记录下来。

import logging logging.basicConfig( filename="monitor.log", level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s", )

然后在整个链路里用 try/except 包裹网络请求：

try: html = fetch_page(url) except requests.RequestException as e: logging.error("抓取失败: %s, 错误: %s", url, e)

这类问题最隐蔽的地方在于，失败本身不会让脚本退出，只是本次循环空转。有了日志之后，绝大多数静默问题都能在第一时间定位。

6. 进阶：把“变了没”升级为“变了啥”，用正文指纹和差异对比减少误报

监控工具稳定跑起来之后，下一步自然会想：光知道页面变了不够，最好能直接看到变了什么。这个需求可以分两层实现：第一层是用正文指纹替代整页哈希，减少无效告警；第二层是保存上次正文快照，对前后两版文本做差异对比，把具体新增和删除的内容提取出来。

正文指纹在 5.4 已经给出，这里补上差异对比的代码。当检测到指纹变化时，从数据库里取出上次的纯文本快照，与当前文本做逐行对比。

import difflib def diff_text(old_text: str, new_text: str) -> dict: old_lines = old_text.strip().splitlines() new_lines = new_text.strip().splitlines() diff = list( difflib.unified_diff( old_lines, new_lines, fromfile="old", tofile="new", lineterm="" ) ) added = [line[1:] for line in diff if line.startswith("+") and not line.startswith("+++")] removed = [line[1:] for line in diff if line.startswith("-") and not line.startswith("---")] return {"added": added, "removed": removed}

对应的存储结构调整也简单：snapshots 表里增加一列 text_snapshot TEXT，每次保存指纹的同时把正文纯文本也存进去。推送的时候就能输出类似“新增 3 行，删除 1 行，第一条新增内容为……”这样的摘要，接收信息的人不用再打开网页核对。

这套差异对比方案还有一个额外收益：可以给通知加严重级别。如果新增内容里包含“上线”“发布”“故障”这类关键词，就走紧急通道；如果只是数字更新或排版调整，就按普通通知处理。我最早做的版本就是发现哈希变化就无脑推送，结果半夜被页面底部的“在线人数”波动吵醒过好几次，后来加了正文指纹和差异对比，误报率才真正降下来。监控工具的价值不在于通知发得勤，而在于每一条通知都值得看。希望帮到你。

本文还有配套的精品资源，点击获取