网页变化实时监控系统设计与实现

一、问题界定：什么是“网页变化监控”

网页变化监控，本质上是一个周期性的差异检测系统：在固定时间间隔内重复获取目标页面的内容，与上一次的结果进行比对，当差异超过预设阈值时触发告警。它并不是“实时”的——真正意义上的实时需要服务端推送或长连接，而通用网页监控只能做到准实时，即时延取决于抓取周期。理解这一点，有助于我们合理设定预期与轮询频率。

一个完整的监控系统需要解决四个核心问题：

1. 采集：如何稳定地拿到网页内容，并处理反爬、超时、重试等情况；
2. 规范化：如何剔除每次请求都会变化的噪声（时间戳、随机 ID、广告位、埋点 token），只保留真正有业务意义的部分；
3. 判定：如何比较两次内容，判断“是否发生了变化”，并且控制误报率；
4. 通知与运维：如何把变化送达用户，以及如何让程序长期稳定运行。

下面按这四个环节展开，并给出可落地的实现思路与代码示例。

二、采集层：定时抓取与健壮性设计

最朴素的实现是“定时请求 + 保存内容”，但工程上需要考虑的细节远不止于此。

抓取周期设定。 周期越短，感知越及时，但对目标站点压力越大、被限流的概率越高。建议根据页面更新频率分级：高频更新的公告页可设为 5～10 分钟，普通内容页设为 1 小时，低频页面设为每天一次。同时应加入随机抖动（jitter），避免固定时刻的大量并发请求形成明显的机器特征。

请求健壮性。 必须设置合理的超时时间（连接超时与读取超时分离），对 5xx 与网络异常做指数退避重试，对 4xx 则不应盲目重试。对于需要登录态的页面，应妥善管理会话凭证；对于动态渲染页面，则需要考虑无头浏览器方案，但要注意其资源开销显著高于纯 HTTP 请求。

内容获取的边界。 只取正文区域而非整页 HTML，可以大幅降低噪声。实践中可优先解析结构化数据（如页面内嵌的 JSON），其次按稳定的 CSS 选择器提取目标区块，最后才回退到全文。

import time
import random
import requests
def fetch(url, session, retries=3, timeout=(5, 15)):
    for attempt in range(retries):
        try:
            resp = session.get(url, timeout=timeout,
                               headers={"User-Agent": "Mozilla/5.0 (compatible; PageWatcher/1.0)"})
            if resp.status_code == 200:
                resp.encoding = resp.apparent_encoding
                return resp.text
            if 400 <= resp.status_code < 500:
                return None  # 客户端错误不重试
        except requests.RequestException:
            pass
        time.sleep((2 ** attempt) + random.uniform(0, 1))
    return None

三、规范化层：让比较只关注“有意义的变化”

这是整个系统中最容易被低估、却最决定成败的环节。原始页面中大量内容每次都不同：CSRF token、随机广告 ID、访问计数、渲染时间戳、A/B 实验参数等。若直接对原始 HTML 做哈希，几乎每次都会“检测到变化”，系统会迅速沦为噪声源。

规范化的常见手段包括：

• 结构裁剪：只保留目标区块的文本内容，丢弃脚本、样式、注释与属性；
• 模式清洗：用正则表达式移除时间戳、UUID、长数字串、随机 query 参数等易变片段；
• 归一化：统一空白字符、去除首尾空行、将相对链接转为占位符；
• 排序稳定化：对无序集合类内容（如标签列表）先排序再比较。

import re
NOISE_PATTERNS = [
    r"\b[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\b",  # UUID
    r"\b\d{4}-\d{2}-\d{2}[ T]\d{2}:\d{2}:\d{2}\b",                        # 时间戳
    r"\btoken=[A-Za-z0-9%._-]+",                                          # 查询参数
    r"\b\d{10,13}\b",                                                     # 长数字串
]
def normalize(text):
    text = re.sub(r"<script.*?</script>|<style.*?</style>", " ", text, flags=re.S | re.I)
    text = re.sub(r"<[^>]+>", " ", text)          # 去标签
    for p in NOISE_PATTERNS:
        text = re.sub(p, "<NOISE>", text)
    text = re.sub(r"\s+", " ", text).strip()      # 空白归一
    return text

需要强调的是，噪声规则必须按站点定制。同一条正则在 A 站有效，在 B 站可能误删真实内容。建议在上线前先采集若干次样本，人工对比差异，确认清洗规则只影响噪声部分。

四、判定层：从哈希比对到相似度判定

哈希比对是最简单的方案：对规范化后的文本计算 SHA-256，值不同即认为有变化。它的优点是实现简单、计算廉价、零误报（在规范化充分的前提下）。缺点是对微小变化极其敏感——哪怕只多了一个标点，也会触发告警，容易造成“狼来了”效应。

相似度判定是更实用的进阶方案。常用做法是将文本切分为词元或字符 n-gram，计算集合的 Jaccard 系数，或使用编辑距离归一化后的相似度。设定阈值（例如相似度低于 99% 才判定为更新），可以过滤掉排版微调、单个字符修正这类低价值变化，同时保留对实质性内容变更的敏感性。

方案	灵敏度	误报率	计算成本	适用场景
SHA-256 哈希	极高	高（噪声敏感）	极低	结构稳定、噪声已彻底清洗的页面
字符 n-gram 相似度	中高	中	低	通用文本页面
分块差异（段落级）	中	低	中	长文档、需要定位变化位置
结构化字段比对	按字段	低	低	价格、库存等结构化数据

import hashlib
def shingles(text, k=5):
    text = text.replace(" ", "")
    return {text[i:i + k] for i in range(max(0, len(text) - k + 1))}
def similarity(old, new):
    a, b = shingles(old), shingles(new)
    if not a and not b:
        return 1.0
    inter = len(a & b)
    union = len(a | b)
    return inter / union if union else 1.0
def is_changed(old, new, threshold=0.99):
    if hashlib.sha256(old.encode()).hexdigest() == hashlib.sha256(new.encode()).hexdigest():
        return False
    return similarity(old, new) < threshold

先做哈希短路判断，再做相似度计算，可以在大多数“无变化”的轮次中省去昂贵的集合运算，兼顾性能与准确性。若需要定位“变了哪里”，可进一步将文本按段落切分，逐段比对并输出差异摘要，这对通知内容的质量提升明显。

五、通知层：让告警可读、可溯源

告警的价值取决于信息质量。一条有效的变更通知应包含：目标页面标识、检测时间、变化程度（相似度或差异段落数）、变化内容摘要，以及原始页面快照的存储位置。仅发送“页面有更新”而不给上下文，会让接收者不得不二次人工核查，削弱系统价值。

通知渠道可选用邮件、Webhook 推送到协作工具、短信等。工程上建议做告警聚合与抑制：同一页面在短时间内多次触发时合并为一条；连续多轮检测到变化时，说明页面可能处于持续更新状态（如实时榜单），此时应自动降频而非反复轰炸。此外，应为每次变更保留历史快照（可存入对象存储），便于回溯与人工确认。

六、部署与长期运行

监控程序需要长期常驻，部署方式直接影响稳定性。

• 进程守护：使用系统服务管理器托管进程，配置自动重启与开机自启，比裸跑后台命令更可靠；
• 日志与可观测性：记录每次抓取的状态码、耗时、内容长度与判定结果，便于排查“为什么没报警”或“为什么一直报警”；
• 状态持久化：上一轮的内容快照与哈希必须落盘（文件或数据库），否则进程重启后会丢失基线，产生一次伪变更；
• 资源控制：无头浏览器实例应复用而非每次新建，并设置并发上限，避免内存持续增长；
• 失败告警：连续多次抓取失败本身也应触发通知，否则系统会“静默失效”，这比误报更危险。

一个常见的启动方式如下（使用系统服务管理器托管，日志重定向到文件）：

# 以 systemd 为例，服务单元中配置：
# ExecStart=/usr/bin/python3 /opt/watcher/main.py
# Restart=always
# RestartSec=10
python3 main.py --config /opt/watcher/sites.yaml >> /var/log/watcher.log 2>&1

配置建议外置为 YAML 或 JSON，按站点声明 URL、选择器、抓取周期、清洗规则与相似度阈值，使新增监控目标无需改动代码。

七、工程实践要点小结

1. 先采样再定规则：对目标页面连续抓取 5～10 次，观察哪些部分天然易变，据此设计清洗规则，避免拍脑袋。
2. 阈值要可调：相似度阈值应按站点配置，并在上线初期观察一周的判定分布后再固化。
3. 区分“变化”与“重要变化”：可通过关键词命中、目标字段比对等方式做二级过滤，把通知留给真正需要人处理的事件。
4. 保留快照：没有历史快照的监控系统无法自证，也无法排查误报。
5. 监控系统本身要被监控：抓取成功率、平均耗时、告警数量都应纳入观测，形成闭环。

结语

网页变化监控看似只是“定时抓取加比对”，但真正决定其可用性的，是规范化策略是否充分、判定阈值是否合理、告警信息是否可行动，以及系统能否长期稳定运行。按照采集、规范化、判定、通知、运维这五个层次分层设计，并以配置驱动的方式管理各站点的差异化规则，就能用较小的工程投入，构建出一套低误报、可维护、可持续演进的网页变更感知能力。对于需要追踪竞品动态、政策公告、库存价格或文档更新的团队而言，这套方案的投入产出比相当可观。