核心分析¶

项目定位：changedetection.io 的核心目标是为用户提供一个可自托管、功能丰富的网页/文档变更检测平台，覆盖静态 HTML、动态 JS 渲染页面、交互流程产生的内容，以及 PDF/JSON 的变化监控。

技术特点¶

• 双路径抓取：默认的轻量 HTTP 抓取用于静态页面；需要时切换到基于 Chromium 的 Playwright/WebDriver 抓取来执行 JS 和交互步骤。
• 丰富的提取/过滤管道：支持 XPath/CSS/JSONPath/jq/正则与忽略/删除规则，以减少噪声并精确定位监控目标。
• 文件与结构化数据支持：内置对 PDF（文本/校验和/大小）和 JSON API 的专门检测逻辑。
• 告警与整合：通过 apprise 支持多种通知渠道（Slack/Email/Discord/Webhook 等）。

使用建议¶

1. 场景匹配：如果你需要监控价格、补货、法规或公告类内容，且希望自托管或加入企业通知流程，changedetection.io 是合适选择。尤其在目标页面包含 JS 渲染或需登录时，它比纯 HTML diff 更实用。
2. 优先级配置：默认使用非JS抓取以节省资源；仅对确实需要的 URL 启用 Playwright。对 PDF/JSON 明确使用对应规则来避免误报。

注意事项¶

• 资源与频率：大量使用 Playwright 会增加 CPU/内存消耗；高频检查需配套代理和更强的主机。
• 反爬与合规：频繁抓取或自动化交互可能触及站点服务条款，必要时调整频率并遵守法律/合规约束。
• 调优需求：复杂页面常需调试浏览器步骤与选择器。

重要提示：若目标页面高度动态或含验证码/复杂行为检测，平台自身通常无法完全绕过这些防护，需要额外方案或人工介入。

总结：changedetection.io 在需要可控、自托管并能处理动态与文件型内容的监控场景中价值高，但在资源与反爬限制高的环境下需谨慎评估并配套运维措施。

核心分析¶

问题核心：如何在需要登录或交互才能得到目标内容的页面上建立稳定的监控流程？

技术分析¶

• Browser Steps 的作用：模拟用户操作（导航、填表、点击、提交），用于获得最终渲染状态。
• Visual Selector 的作用：在交互完成后的 DOM 中可视化定位要监控的元素或区域，减少无关噪声。
• 关键要点：交互脚本必须可重复、幂等；等待条件要可靠（元素可见/文本出现/网络空闲），而不是简单的固定 sleep。

实用建议¶

1. 先在开发环境手工回放并确认步骤稳定：反复在浏览器中执行登录/导航流程，记录必要步骤。
2. 使用显式等待：在 Browser Steps 中等待特定元素可见或特定文本出现，避免仅靠固定延时。
3. 使用稳健选择器：在 Visual Selector 中优先使用稳定的 CSS/XPath（避免基于动态 ID 或随机 class 的选择器）。
4. 会话与凭证管理：对登录站点使用安全存储凭证并处理会话过期与重试逻辑；对双因素或验证码站点考虑人工前置或其他方案。
5. 分步验证：每次修改步骤后，先运行一次并观察快照差异，确认没有误报或漏报。

常见配置错误与影响¶

• 使用固定 sleep 替代显式等待：导致网络慢时失败或不稳定。
• 选择器过宽包含动态内容：产生噪声与误报。
• 未处理会话超时：抓取时间长或凭证失效会导致返回登录页而非目标内容。
• 忽视反爬防护（验证码、行为检测）：脚本会被拦截或触发额外验证步骤。

重要提示：Browser Steps 强大但并非万能。对于验证码或高级行为检测，需额外人工或第三方服务介入。

总结：把 Browser Steps 当成可编程的“按需浏览器”，用显式等待与稳健选择器结合，并在每次变更后进行验证，能显著提高抓取稳定性与减少误报。

核心分析¶

问题核心：如何在变更检测中降低误报并保留有意义的变更？

技术分析¶

• 定位优先：用 Visual Selector 或精确的 CSS/XPath 将监控范围缩到真正关心的 DOM 片段，避免整页 diff。
• 字段清洗：使用 Remove/Ignore 规则、正则替换或 jq 对 JSON 字段进行清洗，剔除时间戳、动态 ID、广告等噪声。
• 条件触发：对数值类（价格、库存）使用阈值或百分比变动触发；对文本类使用关键字/正则触发以避免小幅格式变更造成告警。

实用建议¶

1. 首选精确提取：能用 Visual Selector 选到的就不要做整页监控。精确片段减少不相关变化。
2. 明确忽略列表：列出已知噪声（日期、UUID、广告 DIV），用 Remove/Ignore 或正则把它们替换或删除。
3. 对结构化数据使用 JSONPath/jq：直接抽取目标字段而非整个响应，结合条件触发减少误报。
4. 使用阈值与百分比变化：特别是价格监控，避免每一次小的格式化差异都触发告警。
5. 逐步迭代：上线后观察一段时间的快照/告警日志并根据实际噪声做规则调整。

注意事项¶

• 过度清洗风险：太激进的替换可能掩盖真正有意义的变化，需在生产环境中谨慎调整。
• 复杂动态内容：某些由客户端频繁重排的内容可能需人工判断是否值得监控或降低检查频率。

重要提示：把变更检测当成一个可迭代的监控任务——初期以宽容设置开始，逐步收紧过滤与触发规则。

总结：结合精确选择器、字段清洗与条件触发是降低误报的最佳实践；在高噪声页面上需要持续观测与调优。

核心分析¶

问题核心：changedetection.io 如何检测 PDF 与 JSON 的变化？在什么情况下这些功能会受限？

技术分析¶

• PDF 监控实现：通常通过下载目标 PDF 然后比较文本提取结果或文件级别指标（文件大小、校验和）。如果 PDF 是文字层（不是扫描图片），文本比对可较精确地发现改动。
• JSON 监控实现：通过对响应体使用 JSONPath/jq 等提取器定位特定字段，保存历史值并对字段差异触发通知；也可用正则或哈希对某些片段进行比对。

局限性¶

1. 扫描 PDF（图片型）：需要 OCR 才能比较文字，OCR 本身带来误差并可能产生噪声或漏检。
2. 动态/频繁重构的 JSON：如果 API 经常改变字段路径或版本升级，提取规则会失效，需要维护 JSONPath/jq 表达式。
3. 大型文件与性能：大型 PDF/JSON 处理会增加 CPU/内存使用，可能需要对提取区域或字段进行限制。
4. 格式化变化 vs 语义变化：格式或排版的小改动（空格、格式化）在文本比对中可能被视为变化，需借助清洗规则或更智能的差异判定。

实用建议¶

1. 对可提取文本的 PDF 使用文本比对并设置忽略/正则规则去除日期或脚注等噪声；对扫描件考虑预处理 OCR 并接受更高噪声率。
2. 对 JSON 使用稳定的 JSONPath/jq 指定字段，并在 API 发布周期内安排规则验证；对关键字段使用数值阈值或类型校验减少误报。
3. 对大文件限制提取范围或使用哈希来检测是否需要更深层比较。

重要提示：PDF 与 JSON 支持显著扩展了适用场景，但在遇到扫描件或非稳定 API 时需要额外的工程投入以保证准确性。

总结：changedetection.io 的 PDF/JSON 功能在大多数可提取文本和结构化 API 场景下非常有用；对于扫描 PDF、OCR 需求高或 API 结构频繁变更的场景，需要额外策略与维护。