盯住网页改动并自动通知（changedetection.io）

网页上的关键信息什么时候变，多数站点不会告诉你。价格页、库存页、招聘页、政府公告、安全通告、PDF 文件，更新往往悄无声息，多数站点也不提供 RSS。changedetection.io 把定时抓取、差异比对、触发通知这三件事装进一个可以自己部署的 Web 应用，配置全部在浏览器界面里完成。

changedetection.io 是用 Python 写的自托管网页变更监控工具，输入一组要盯的网址，输出变更差异与通知，用于盯价格、库存、公告与页面篡改。

典型用法是把它长期挂在服务器上，按设定的间隔重新抓取每个页面，把新旧内容做对比，命中你关心的变化就发出去。README 列出的用例包括补货提醒、降价提醒、PDF 文本变化、JSON API 响应变化、招聘页关键字、法律与合规文档更新，也包括网站被篡改的监测。通知渠道覆盖 Discord、Email、Slack、Telegram 与 Webhook。

它不做什么

自托管版本的部署与长期维护由你自己负责。项目另有托管订阅方案，README 里标价 $8.99/月，走的是别人替你跑代理和运维的路线。

AI 变更摘要与 AI 变更规则这两项，README 明确标注为 Available in our subscription/hosted service from June 2026，开源自托管版本是否包含，仓库里没有说明。Visual Selector 的可视化元素选择要在接入 playwright content fetcher 时才能用，README 注明该 fetcher 包含在订阅服务中。

默认抓取不执行页面上的 JavaScript。要处理 JS 渲染出来的内容，得换用 WebDriver 或 Playwright 抓取方式，Browser Steps 也要求先启用 Playwright。项目也不承诺穿透反爬，Issue 列表里有一条待解决的 Improve 「bot-detection」 evasion techniques，是用户提出的规避技术改进请求，目前仍是开放状态。

用之前先准备好什么

• 一台能长期在线的主机。监控靠按间隔轮询，机器一停就没有通知。
• 容器运行时，或者一套 Python 环境。仓库根目录同时带 Dockerfile 与 docker-compose.yml，另外有 setup.py、requirements.txt、README-pip.md，说明 pip 安装也是一条官方路径。
• 一份要监控的 URL 清单，以及每个页面里你真正关心的那部分内容——整页对比通常噪音很大。
• 通知渠道的接入信息，比如 Webhook 地址、Bot Token、SMTP 参数。README 只列出支持哪些渠道，没有给出每个渠道的配置字段。
• 需要登录才能看到内容的页面，用 Browser Steps 预先填表单、点按钮，账号凭据由你自己准备。

主要功能

• 网页变更监控与多渠道通知：把 URL 加进 watchlist，设定检查频率，内容变化后通过 Discord、Email、Slack、Telegram、Webhook 等渠道发提醒。
• 差异对比：变更详情可以按词、按行、按单个字符三种粒度查看，用来判断改动是一处价格数字，还是整块导航被重排。
• 触发器过滤：README 的 Key Features 里举了 Trigger on text 一类的过滤器，用来只在特定文本出现或消失时才通知。这一节在拿到的 README 节选里被截断，完整的过滤器清单要看仓库原文。
• 单商品页的库存与价格监控：打开 Re-stock & Price detection for single product pages 后，工具会从页面 HTML 的元数据里提取价格信息，可以设置价格上限、下限与价格变化百分比来触发通知，并在图表里看历史走势。
• Browser Steps：抓取之前先跑一段浏览器操作，例如登录网站、把商品加入购物车、接受 cookie 弹窗、填日期、收窄搜索结果，用来监控藏在交互后面的内容。
• Visual Selector：在页面上直接点选要监控的区域和元素，先跑完 Browser Steps，再切到这个标签页细化选取范围。
• JS 渲染抓取：支持 WebDriver 与 Playwright 两种带浏览器的方式，处理前端渲染的页面。
• 非 HTML 输入与 RSS 输出：可以监控 JSON API 的响应变化、跟踪 PDF 文件里的文本改动，也可以把内容变化做成 RSS 订阅源。

安装与最短示例

仓库地址是 https://github.com/dgtlmoon/changedetection.io，Apache-2.0 许可证，主要语言 Python（占 79.0%）。开源路径有两条：容器与 pip。

# 仓库根目录已提供的部署相关文件
docker-compose.yml
Dockerfile
docker-entrypoint.sh
README-pip.md
setup.py
requirements.txt

拿到的 README 节选在安装章节之前就被截断，镜像名、默认端口、环境变量这些仓库里没有在这段内容中给出，需要对照 README 与 docker-compose.yml 原文。仓库里没有说明这一步，我不替它补。

最短能跑通的流程走的是界面，不是命令：服务起来之后用浏览器进入界面，新增一条要监控的 URL 加进 watchlist；如果盯的是商品页，打开 Re-stock & Price detection for single product pages；如果页面需要先登录，配好 Browser Steps；最后选一个通知渠道填上参数。这四步之后，下一次内容变化就会推到你选的那个渠道里。

关键参数

Re-stock & Price detection for single product pages   # 单商品页的库存与价格监控开关
Browser Steps                                          # 抓取前执行的浏览器交互步骤
Visual Selector                                        # 在页面上点选要监控的元素
Trigger on text                                        # 触发器过滤器之一
OpenAI-compatible (vLLM, LM Studio, llama.cpp)         # LLM 提供方下拉项

Re-stock & Price detection for single product pages 配套的是价格上限、价格下限、价格变化百分比这几个通知参数，README 里对应的设置界面写的是 upper and lower price、price change percentage。

LLM 相关配置在 README 里写的是支持 OpenAI、Gemini、Anthropic、Ollama，以及能填 /v1 地址的自建服务，下拉项里对应 OpenAI-compatible (vLLM, LM Studio, llama.cpp)。这一块由 LiteLLM 驱动，README 说覆盖 100+ 提供方与模型。要注意这些能力 README 标注为订阅与托管服务提供。

Issue 里还出现过 Recheck 这个操作入口，用于手动重查某个已添加的监控项。

结果在哪里看

主要的输出去向有四个。第一是 watchlist 界面，每条监控项的状态、上次检查时间与是否触发都列在这里。第二是差异视图，可以按词、按行、按单个字符切换查看改动细节。第三是价格趋势图，只有打开了单商品页的价格监控才有。第四是通知渠道本身，以及可以把变更做成 RSS 订阅源。

实际使用中的坑

• 空白 diff 也会触发通知：Issue 里反馈过一部分站点会发来「有变化」的通知，但打开差异是空的，原因是过滤条件可用性发生波动。这条已经标记为已解决，评论区 135 条，是评论最多的一个问题。
• 304 Not Modified 缓存处理在反代场景下会让请求失败：Issue 记录显示这是上游问题引起，运行在反向代理后面时更容易碰到。目前状态是待解决。
• 部分 xpath 过滤器报错：现象是 'str' object has no attribute '__name__'，只在某些 xpath 过滤器上出现，Issue 目前待解决。
• 批量重查时更新失败：Realtime updates 下同时排队检查多个站点，有时会出现更新失败，Issue 记录的平台是 Docker 容器 v0.52.1，目前待解决。

横向对照

后两个项目放进这张表，是因为它们和 changedetection.io 处在相邻的选型位置，但要做的事并不相同：netdata 是基础设施指标方向，crawl4ai 是抓取与内容整理方向，都不提供「页面内容变了就通知我」这条链路，这里只是给同类选型的读者一个参照。

反过来说，如果你要的是大规模抓取并把正文整段喂给大模型，changedetection.io 不是合适的工具，它的抓取是为差异比对服务的，输出的是改了哪里；crawl4ai 那类项目更对路。如果你要的是服务器 CPU、内存、网络这些颗粒度很细的指标，netdata 覆盖得比一个网页监控工具深得多。它的 AI 变更摘要目前也只在订阅与托管服务里提供，不想付费又要 AI 判断的话，得自己接模型。

合规与授权边界

这个项目的核心动作是周期性抓取网页，所以使用边界要先说清楚：只对你自己拥有的资产，或者已经拿到明确授权的目标做监控。未经许可对第三方站点做高频轮询，可能违反目标站点的服务条款，也可能触发当地关于计算机访问与数据获取的法律风险，被平台封 IP、封账号是常见后果。

Browser Steps 支持登录后抓取，这一步尤其要注意：用别人的账号登录别人系统去拉数据，性质和爬公开页面不一样。价格与库存监控在零售场景里用得很广，但同样要控制在对方允许的访问频率内。项目本身不替你做授权判断，Issue 里那条关于避让 bot 检测的请求目前仍待解决，也说明抓取能否成功取决于目标站点的策略。

适合谁

适合想把监控数据握在自己手里的开发者和运维，手上有一批具体页面要盯，比如十几个竞品价格页、几十家供应商的库存页、自己公司的对外公告页，并且愿意为容器和通知渠道做一次配置。也适合本身就有服务器、不想为这类功能按月付费的人。

适合能接受一点折腾的人：JS 渲染要另配抓取器，登录页面要配 Browser Steps，AI 摘要要用就得走订阅或自己接模型。反过来，如果你只想打开网页填个邮箱就完事，或者要监控的是成千上万个域名级别的抓取任务，这个项目的形态并不合适。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.9 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。