网页内容监控有很大一块需求落在“某个区块又变了”上面价格、公告、版本号、招聘状态、新闻标题这些页面都不是整页重写而是局部区域在变化。Pounce 这类工具对应的正是这种粒度的监控用户不写采集规则而是在页面上点一下目标元素工具记录下当前内容之后定期采集并比对发现不一致就发出通知。拆开看这个需求一点也不复杂但真正要做到“点一下就能长期监控、少误报、少漏报”需要处理选择器稳定性、内容提取口径、调度频率、状态保存和通知失败重试等一系列问题。这篇文章从这类工具要解决的问题出发带着你跑通一个最小原型再讨论哪些位置最容易出坑。1. 把“点一下元素内容变了通知我”拆成技术链路1.1 用户说的“元素”在 DOM 里是什么用户眼睛里的“一个元素”通常是页面上一个可见区块一个价格、一行版本号、一个库存状态、一条招聘标题。但从程序角度看用户点击命中的其实是一个 DOM 节点。要监控这个节点必须先把“用户点了哪里”转换成机器能长期保存的定位信息也就是 CSS 选择器或 XPath 这类寻址表达式。定位方式确定后还要确定“监控这个元素的什么”。不同场景要提取的值完全不同监控价格时通常取innerText但要注意页面里展示的是“价格”DOM 里可能还带货币符号。监控链接是否更换时要取href属性而不是元素文本。监控按钮是否可点击时可能要取disabled属性或aria-disabled。监控表格是否拆分时取innerHTML会更直观但也会带回更多噪音。所以 Pounce 类工具最终保存的监控项不是简单一段“网页地址 一句关键词”而是“在哪个 URL、等哪个选择器、取什么内容、和谁比、变化后通知谁”。1.2 完整链路选点、采集、比对、通知一次完整的元素级监控流程可以拆成下面几步用户进入页面进入“选点模式”点击目标元素。前端脚本把点击坐标转成元素再把元素转成 CSS 选择器。系统保存一条监控记录URL、选择器、提取口径、通知地址。定时任务按周期打开页面等待页面渲染完成。后端脚本查找到目标元素按配置提取文本、属性或局部 HTML。对提取结果做归一化并生成内容指纹。与上一次保存的内容指纹比较。相同则只更新时间戳不同则更新指纹并发送通知。这个链路里最容易出问题的不是最后一步通知而是第 2、5、6 步。选择器不稳定会导致后面全部都查不到提取口径不统一会导致每次内容都不一样内容归一化做得不够会导致“明明没变却一直报警”。1.3 用哈希而不是全文比较为什么要这样做比较两个版本是否一致时最直接的做法是把新文本和旧文本逐字比较。但真实监控任务里同一个元素的内容可能很大也可能是很长一段表格逐字比较既费内存还会把大量中间状态保留下来。更常见的做法是只保存内容的摘要值也就是哈希import { createHash } from node:crypto; function fingerprint(text) { return createHash(sha256).update(text).digest(hex); }每次采集后先归一化文本再计算 SHA-256。lastHash保存的是上一次已通知状态的内容摘要。新哈希与旧哈希不同就说明目标内容发生了变化。这种做法有一个重要前提只有把“和变化判断无关的信息”都从文本里剔除后哈希比较才有意义。否则页面里哪怕只多了一个随机生成的零宽字符也会被判断成一次变化。这一点后面单独展开。2. 页面选点把点击坐标变成能长期保存的选择器2.1 不让用户手写选择器picker 模式与 elementFromPoint让普通用户去理解 CSS 选择器并不现实。Pounce 类工具的交互目标是一句话你点一下页面上的内容剩下的交给工具。实现选点功能时需要进入一种“页面拾取模式”。在该模式下用户鼠标经过元素时页面显示高亮边框用户点击目标元素时脚本读取该元素并生成选择器而不是把默认点击行为触发掉。关键点是不要用event.target直接判断用户点到了谁。因为用户可能点到元素内部的文字节点、图片或者某个子级 span直接用点击事件绑定的target很可能拿到比预想更细的节点。更稳妥的做法是用坐标反查页面当前最上层的元素document.addEventListener(click, (event) { if (!window.__pickingEnabled) return; const target document.elementFromPoint(event.clientX, event.clientY); const selector generateCssSelector(target); console.log(目标选择器:, selector); event.preventDefault(); event.stopPropagation(); }, true);需要在捕获阶段监听并且阻止默认行为。否则用户一点按钮可能按钮的点击逻辑先执行造成页面跳转或弹窗导致选择器生成逻辑被打断。2.2 生成 CSS 选择器的最小代码从 DOM 节点生成选择器时可以优先使用元素自带的id因为它最短、最稳定。如果元素没有id就沿着父级向上走用标签名和nth-of-type拼出唯一路径。function generateCssSelector(node) { if (!(node instanceof Element)) return null; if (node.id) return # CSS.escape(node.id); const parts []; let current node; while (current current.nodeType Node.ELEMENT_NODE) { if (current.id) { parts.unshift(# CSS.escape(current.id)); break; } const tag current.tagName.toLowerCase(); const parent current.parentElement; if (parent) { const sameTagSiblings Array.from(parent.children) .filter((child) child.tagName current.tagName); const position sameTagSiblings.indexOf(current) 1; parts.unshift(position 1 ? ${tag}:nth-of-type(${position}) : tag); } else { parts.unshift(tag); } current parent; } return parts.join( ); }实际使用时还要记得处理input、button这类元素并考虑用name、aria-label增强可读性。如果页面结构复杂建议选择器生成后回到浏览器控制台验证一下document.querySelectorAll(你生成的选择器).length返回 1 才说明选择器能唯一定位到目标元素。返回 0 是查不到返回大于 1 说明选择器定位到了多个节点后续采集时可能出现错误结果。2.3 更稳定的定位不要迷信结构路径自动生成的选择器有一个共同弱点它会包含很多结构层级信息。页面改版时只要某个父容器多包了一层 div后面所有nth-of-type的序号都可能失效。生产级选择器需要做两层改进第一优先使用语义化属性。不少页面会在按钮、卡片、价格区域上留下>mkdir pounce-demo cd pounce-demo npm init -y npm install puppeteer node-cron示例依赖puppeteer和node-cron。前者负责无头浏览器采集后者负责定时调度。实际项目落地前需要确认本机 Node.js 版本和项目依赖兼容性不要直接假定安装的就是某个固定版本。项目里建议保留 4 个文件pounce-demo/ ├── package.json ├── page-picker.html ├── watches.json └── collector.mjspage-picker.html用来在真实浏览器里生成选择器watches.json保存监控配置collector.mjs是核心采集脚本。3.2 用来描述“监控什么”的 watches.json监控配置表结构决定了整个系统的能力边界。最小字段可以这样设计[ { id: release-note-title, name: 发布说明版本号, url: https://example.com/changelog, selector: #changelog .release-title, mode: text, notifyWebhook: https://your-server.example.com/webhook/pounce, enabled: true } ]字段含义如下字段含义说明id监控项编号全局唯一通知内容里应带上这个字段name监控项名称方便人识别不参与逻辑判断url目标页面地址必须是完整可访问的 URLselector目标元素选择器建议由 picker 页面生成mode取内容的方式常见值text、html、hrefnotifyWebhook通知地址可省略省略时只记录变化不通知enabled是否启用停用时不参与任何调度和采集lastHash这类运行状态可以放到同一份文件也可以单独拆成状态文件。为了演示简单这里先放在同一个 JSON 对象里。3.3 collector 核心代码collector.mjs的最小版本实现如下。这段代码已经包含加载配置、采集文本、归一化、指纹比较、状态更新和通知的基本逻辑。import { createHash } from node:crypto; import fs from node:fs/promises; import puppeteer from puppeteer; const STATE_FILE new URL(./watches.json, import.meta.url); async function loadWatches() { const raw await fs.readFile(STATE_FILE, utf8); return JSON.parse(raw); } async function saveWatches(watches) { const tmp ${STATE_FILE.pathname}.tmp; await fs.writeFile(tmp, JSON.stringify(watches, null, 2), utf8); await fs.rename(tmp, STATE_FILE); } function normalize(raw) { return raw .replace(/\u00a0/g, ) .replace(/\s/g, ) .trim(); } function fingerprint(text) { return createHash(sha256).update(text).digest(hex); } async function fetchPageText(browser, watch) { const page await browser.newPage(); try { await page.goto(watch.url, { waitUntil: networkidle2, timeout: 45000 }); const element await page.$(watch.selector); if (!element) { throw new Error(selector-not-found: ${watch.selector}); } const value await page.evaluate((el) { return (el.innerText || el.value || ).trim(); }, element); if (!value) { throw new Error(element-empty); } return normalize(value); } finally { await page.close(); } } async function notify(watch, text) { if (!watch.notifyWebhook) return; const response await fetch(watch.notifyWebhook, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ watchId: watch.id, name: watch.name, url: watch.url, selector: watch.selector, content: text.slice(0, 2000), changedAt: new Date().toISOString() }) }); if (!response.ok) { throw new Error(notify-failed: ${response.status}); } } async function checkWatch(browser, watch) { const text await fetchPageText(browser, watch); const newHash fingerprint(text); if (watch.lastHash watch.lastHash ! newHash) { await notify(watch, text); console.log([changed] ${watch.name} | ${watch.selector}); } else { console.log([same] ${watch.name} | ${watch.selector}); } watch.lastHash newHash; } async function runAll() { const watches await loadWatches(); const browser await puppeteer.launch({ headless: true }); try { for (const watch of watches.filter((item) item.enabled)) { try { await checkWatch(browser, watch); } catch (error) { console.error([error] ${watch.name}: ${error.message}); } } } finally { await browser.close(); } await saveWatches(watches); } runAll().catch((error) { console.error(error); process.exit(1); });这段代码有几个细节值得说明第一次运行某条监控时lastHash为null脚本只记录当前内容为基线不发送通知。这是有意设计避免用户刚创建监控就被历史旧内容轰炸。通知失败时watch.lastHash不会被更新下一次运行会继续尝试通知同一次变化。文件保存采用先写临时文件再rename的方式减少中断导致配置文件损坏的概率。headless: true表示不打开可见浏览器界面适合服务器环境本地调试时改成headless: false更容易观察页面行为。3.4 第一次运行的意义先建立基线再谈变化运行命令很简单node collector.mjs第一次运行如果正常日志会显示类似[same] 发布说明版本号并且watches.json里被写入lastHash。这个动作相当于完成了一次快照之后所有变化判断都以这次快照为参照。等到目标页面内容真的发生变化后再一次运行脚本日志会变成[changed] 发布说明版本号同时 webhook 会收到一条通知。这里要注意真实页面上很多内容会经常变化比如访问量、时间戳、随机推荐位所以判断是否变化的逻辑不能只比较原始文本。4. “变化”的定义必须收敛提取、归一化与防抖4.1 为什么 innerText 和 innerHTML 不同很多第一次做元素变化监控的人会直接比较元素的innerHTML结果误报率高得惊人。原因很简单innerHTML包含的是 DOM 结构快照不只是用户能看到的文字。同样的视觉结果可能有多种 HTML 写法span价格 b99/b 元/spanspan价格 b99/b 元/span这两段 HTML 用innerHTML比较可能不同但在页面上看起来没有差异。而innerText返回的是用户可感知的渲染文本会把不可见的样式差异过滤掉一部分更适合监控“显示内容”。反过来如果监控目标是“图片被换掉了”或“某个链接跳转地址变了”只看innerText又不够还需要额外提取src、href或alt属性。所以提取口径必须和监控目标绑定。4.2 把“提取内容”抽成 value mode再归一化更通用的做法是给每条监控配置增加一个mode字段由它决定采集脚本应返回什么值function pickValue(element, watch) { const mode watch.mode || text; if (mode html) { return element.innerHTML.trim(); } if (mode href) { return element.href || ; } if (watch.attrName) { return element.getAttribute(watch.attrName) || ; } return (element.innerText || element.value || ).trim(); }提取完原始值后再进入归一化阶段。下面这个函数只处理了几类常见噪音示意意义大于直接照搬function normalize(raw) { return raw .replace(/\u00a0/g, ) .replace(/\u200b/g, ) .replace(/\s/g, ) .trim(); }归一化时要注意不要想一次性把所有可能的噪音都去掉。比如把日期统一成固定文本、把数字全部去掉都可能在“识别真实变化”时帮倒忙。理想做法是每个监控任务可以配置自己的归一化规则。4.3 瞬时闪烁造成的假变化用“二次确认”解决有些网站内容在用户操作时会短暂变化比如“库存紧张”在几秒内变成“已售罄”随后又恢复。这种情况下第一次变化是真实的瞬时事件但如果监控任务的目标是“最终稳定状态”就不应该在瞬时变化时立刻通知。更稳妥的做法是引入两阶段确认。大致逻辑如下当前内容和lastStableHash不同把内容记为pendingHash。下一次采集时如果内容仍然是pendingHash说明变化持续存在于是更新lastStableHash并发送通知。如果下一次采集时内容回到lastStableHash则清空pendingHash不通知。它不能解决所有问题因为两次采集之间的瞬态变化仍然可能被漏掉但能明显减少“只出现几秒钟”的假变化。监控频率越密这一机制越有价值。5. 调度、状态保存与通知重试要一起设计5.1 定时精度与频率怎么选最小原型用命令行手工执行只适合验证逻辑。实际使用需要定时任务驱动常见选择是node-cronimport cron from node-cron; import { runAll } from ./collector.mjs; console.log(监控任务已启动每 5 分钟执行一次); cron.schedule(*/5 * * * *, () { runAll().catch((error) { console.error(scheduler error:, error); }); });如果写成这样的定时任务前面collector.mjs底部的那次直接调用就要去掉或者改成只有通过命令行单独执行时才触发。否则导入模块时也会立刻执行一次全量采集。监控频率的选择要区分场景。学习实验环境可以设置很短间隔比如 1 分钟。生产环境需要考虑三件事页面变化本身的时效性要求新闻、库存类可以高频文档版本类一天一次也能接受。目标服务的压力频率过高会给别人网站带去不必要的流量。通知噪音频率越高越容易把中间态当作最终态。5.2 状态文件要保证安全和可回滚Demo 里的watches.json是“配置 状态”放在同一个文件里。这样做的好处是文件少、逻辑简单坏处是不够健壮。真实项目建议至少把下面这些字段分开保存状态字段意义lastHash最近一次已确认内容指纹lastCheckedAt最近一次成功检查时间lastChangedAt最近一次确认变化时间failureCount连续失败次数用于告警和熔断当一个监控任务连续失败时不应该立刻把它标记为“内容变化”更不能让失败状态影响lastHash。如果因为页面超 网页局部内容监控怎么做？从选点定位到哈希比对的完整技术解析
网页内容监控有很大一块需求落在“某个区块又变了”上面价格、公告、版本号、招聘状态、新闻标题这些页面都不是整页重写而是局部区域在变化。Pounce 这类工具对应的正是这种粒度的监控用户不写采集规则而是在页面上点一下目标元素工具记录下当前内容之后定期采集并比对发现不一致就发出通知。拆开看这个需求一点也不复杂但真正要做到“点一下就能长期监控、少误报、少漏报”需要处理选择器稳定性、内容提取口径、调度频率、状态保存和通知失败重试等一系列问题。这篇文章从这类工具要解决的问题出发带着你跑通一个最小原型再讨论哪些位置最容易出坑。1. 把“点一下元素内容变了通知我”拆成技术链路1.1 用户说的“元素”在 DOM 里是什么用户眼睛里的“一个元素”通常是页面上一个可见区块一个价格、一行版本号、一个库存状态、一条招聘标题。但从程序角度看用户点击命中的其实是一个 DOM 节点。要监控这个节点必须先把“用户点了哪里”转换成机器能长期保存的定位信息也就是 CSS 选择器或 XPath 这类寻址表达式。定位方式确定后还要确定“监控这个元素的什么”。不同场景要提取的值完全不同监控价格时通常取innerText但要注意页面里展示的是“价格”DOM 里可能还带货币符号。监控链接是否更换时要取href属性而不是元素文本。监控按钮是否可点击时可能要取disabled属性或aria-disabled。监控表格是否拆分时取innerHTML会更直观但也会带回更多噪音。所以 Pounce 类工具最终保存的监控项不是简单一段“网页地址 一句关键词”而是“在哪个 URL、等哪个选择器、取什么内容、和谁比、变化后通知谁”。1.2 完整链路选点、采集、比对、通知一次完整的元素级监控流程可以拆成下面几步用户进入页面进入“选点模式”点击目标元素。前端脚本把点击坐标转成元素再把元素转成 CSS 选择器。系统保存一条监控记录URL、选择器、提取口径、通知地址。定时任务按周期打开页面等待页面渲染完成。后端脚本查找到目标元素按配置提取文本、属性或局部 HTML。对提取结果做归一化并生成内容指纹。与上一次保存的内容指纹比较。相同则只更新时间戳不同则更新指纹并发送通知。这个链路里最容易出问题的不是最后一步通知而是第 2、5、6 步。选择器不稳定会导致后面全部都查不到提取口径不统一会导致每次内容都不一样内容归一化做得不够会导致“明明没变却一直报警”。1.3 用哈希而不是全文比较为什么要这样做比较两个版本是否一致时最直接的做法是把新文本和旧文本逐字比较。但真实监控任务里同一个元素的内容可能很大也可能是很长一段表格逐字比较既费内存还会把大量中间状态保留下来。更常见的做法是只保存内容的摘要值也就是哈希import { createHash } from node:crypto; function fingerprint(text) { return createHash(sha256).update(text).digest(hex); }每次采集后先归一化文本再计算 SHA-256。lastHash保存的是上一次已通知状态的内容摘要。新哈希与旧哈希不同就说明目标内容发生了变化。这种做法有一个重要前提只有把“和变化判断无关的信息”都从文本里剔除后哈希比较才有意义。否则页面里哪怕只多了一个随机生成的零宽字符也会被判断成一次变化。这一点后面单独展开。2. 页面选点把点击坐标变成能长期保存的选择器2.1 不让用户手写选择器picker 模式与 elementFromPoint让普通用户去理解 CSS 选择器并不现实。Pounce 类工具的交互目标是一句话你点一下页面上的内容剩下的交给工具。实现选点功能时需要进入一种“页面拾取模式”。在该模式下用户鼠标经过元素时页面显示高亮边框用户点击目标元素时脚本读取该元素并生成选择器而不是把默认点击行为触发掉。关键点是不要用event.target直接判断用户点到了谁。因为用户可能点到元素内部的文字节点、图片或者某个子级 span直接用点击事件绑定的target很可能拿到比预想更细的节点。更稳妥的做法是用坐标反查页面当前最上层的元素document.addEventListener(click, (event) { if (!window.__pickingEnabled) return; const target document.elementFromPoint(event.clientX, event.clientY); const selector generateCssSelector(target); console.log(目标选择器:, selector); event.preventDefault(); event.stopPropagation(); }, true);需要在捕获阶段监听并且阻止默认行为。否则用户一点按钮可能按钮的点击逻辑先执行造成页面跳转或弹窗导致选择器生成逻辑被打断。2.2 生成 CSS 选择器的最小代码从 DOM 节点生成选择器时可以优先使用元素自带的id因为它最短、最稳定。如果元素没有id就沿着父级向上走用标签名和nth-of-type拼出唯一路径。function generateCssSelector(node) { if (!(node instanceof Element)) return null; if (node.id) return # CSS.escape(node.id); const parts []; let current node; while (current current.nodeType Node.ELEMENT_NODE) { if (current.id) { parts.unshift(# CSS.escape(current.id)); break; } const tag current.tagName.toLowerCase(); const parent current.parentElement; if (parent) { const sameTagSiblings Array.from(parent.children) .filter((child) child.tagName current.tagName); const position sameTagSiblings.indexOf(current) 1; parts.unshift(position 1 ? ${tag}:nth-of-type(${position}) : tag); } else { parts.unshift(tag); } current parent; } return parts.join( ); }实际使用时还要记得处理input、button这类元素并考虑用name、aria-label增强可读性。如果页面结构复杂建议选择器生成后回到浏览器控制台验证一下document.querySelectorAll(你生成的选择器).length返回 1 才说明选择器能唯一定位到目标元素。返回 0 是查不到返回大于 1 说明选择器定位到了多个节点后续采集时可能出现错误结果。2.3 更稳定的定位不要迷信结构路径自动生成的选择器有一个共同弱点它会包含很多结构层级信息。页面改版时只要某个父容器多包了一层 div后面所有nth-of-type的序号都可能失效。生产级选择器需要做两层改进第一优先使用语义化属性。不少页面会在按钮、卡片、价格区域上留下>mkdir pounce-demo cd pounce-demo npm init -y npm install puppeteer node-cron示例依赖puppeteer和node-cron。前者负责无头浏览器采集后者负责定时调度。实际项目落地前需要确认本机 Node.js 版本和项目依赖兼容性不要直接假定安装的就是某个固定版本。项目里建议保留 4 个文件pounce-demo/ ├── package.json ├── page-picker.html ├── watches.json └── collector.mjspage-picker.html用来在真实浏览器里生成选择器watches.json保存监控配置collector.mjs是核心采集脚本。3.2 用来描述“监控什么”的 watches.json监控配置表结构决定了整个系统的能力边界。最小字段可以这样设计[ { id: release-note-title, name: 发布说明版本号, url: https://example.com/changelog, selector: #changelog .release-title, mode: text, notifyWebhook: https://your-server.example.com/webhook/pounce, enabled: true } ]字段含义如下字段含义说明id监控项编号全局唯一通知内容里应带上这个字段name监控项名称方便人识别不参与逻辑判断url目标页面地址必须是完整可访问的 URLselector目标元素选择器建议由 picker 页面生成mode取内容的方式常见值text、html、hrefnotifyWebhook通知地址可省略省略时只记录变化不通知enabled是否启用停用时不参与任何调度和采集lastHash这类运行状态可以放到同一份文件也可以单独拆成状态文件。为了演示简单这里先放在同一个 JSON 对象里。3.3 collector 核心代码collector.mjs的最小版本实现如下。这段代码已经包含加载配置、采集文本、归一化、指纹比较、状态更新和通知的基本逻辑。import { createHash } from node:crypto; import fs from node:fs/promises; import puppeteer from puppeteer; const STATE_FILE new URL(./watches.json, import.meta.url); async function loadWatches() { const raw await fs.readFile(STATE_FILE, utf8); return JSON.parse(raw); } async function saveWatches(watches) { const tmp ${STATE_FILE.pathname}.tmp; await fs.writeFile(tmp, JSON.stringify(watches, null, 2), utf8); await fs.rename(tmp, STATE_FILE); } function normalize(raw) { return raw .replace(/\u00a0/g, ) .replace(/\s/g, ) .trim(); } function fingerprint(text) { return createHash(sha256).update(text).digest(hex); } async function fetchPageText(browser, watch) { const page await browser.newPage(); try { await page.goto(watch.url, { waitUntil: networkidle2, timeout: 45000 }); const element await page.$(watch.selector); if (!element) { throw new Error(selector-not-found: ${watch.selector}); } const value await page.evaluate((el) { return (el.innerText || el.value || ).trim(); }, element); if (!value) { throw new Error(element-empty); } return normalize(value); } finally { await page.close(); } } async function notify(watch, text) { if (!watch.notifyWebhook) return; const response await fetch(watch.notifyWebhook, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ watchId: watch.id, name: watch.name, url: watch.url, selector: watch.selector, content: text.slice(0, 2000), changedAt: new Date().toISOString() }) }); if (!response.ok) { throw new Error(notify-failed: ${response.status}); } } async function checkWatch(browser, watch) { const text await fetchPageText(browser, watch); const newHash fingerprint(text); if (watch.lastHash watch.lastHash ! newHash) { await notify(watch, text); console.log([changed] ${watch.name} | ${watch.selector}); } else { console.log([same] ${watch.name} | ${watch.selector}); } watch.lastHash newHash; } async function runAll() { const watches await loadWatches(); const browser await puppeteer.launch({ headless: true }); try { for (const watch of watches.filter((item) item.enabled)) { try { await checkWatch(browser, watch); } catch (error) { console.error([error] ${watch.name}: ${error.message}); } } } finally { await browser.close(); } await saveWatches(watches); } runAll().catch((error) { console.error(error); process.exit(1); });这段代码有几个细节值得说明第一次运行某条监控时lastHash为null脚本只记录当前内容为基线不发送通知。这是有意设计避免用户刚创建监控就被历史旧内容轰炸。通知失败时watch.lastHash不会被更新下一次运行会继续尝试通知同一次变化。文件保存采用先写临时文件再rename的方式减少中断导致配置文件损坏的概率。headless: true表示不打开可见浏览器界面适合服务器环境本地调试时改成headless: false更容易观察页面行为。3.4 第一次运行的意义先建立基线再谈变化运行命令很简单node collector.mjs第一次运行如果正常日志会显示类似[same] 发布说明版本号并且watches.json里被写入lastHash。这个动作相当于完成了一次快照之后所有变化判断都以这次快照为参照。等到目标页面内容真的发生变化后再一次运行脚本日志会变成[changed] 发布说明版本号同时 webhook 会收到一条通知。这里要注意真实页面上很多内容会经常变化比如访问量、时间戳、随机推荐位所以判断是否变化的逻辑不能只比较原始文本。4. “变化”的定义必须收敛提取、归一化与防抖4.1 为什么 innerText 和 innerHTML 不同很多第一次做元素变化监控的人会直接比较元素的innerHTML结果误报率高得惊人。原因很简单innerHTML包含的是 DOM 结构快照不只是用户能看到的文字。同样的视觉结果可能有多种 HTML 写法span价格 b99/b 元/spanspan价格 b99/b 元/span这两段 HTML 用innerHTML比较可能不同但在页面上看起来没有差异。而innerText返回的是用户可感知的渲染文本会把不可见的样式差异过滤掉一部分更适合监控“显示内容”。反过来如果监控目标是“图片被换掉了”或“某个链接跳转地址变了”只看innerText又不够还需要额外提取src、href或alt属性。所以提取口径必须和监控目标绑定。4.2 把“提取内容”抽成 value mode再归一化更通用的做法是给每条监控配置增加一个mode字段由它决定采集脚本应返回什么值function pickValue(element, watch) { const mode watch.mode || text; if (mode html) { return element.innerHTML.trim(); } if (mode href) { return element.href || ; } if (watch.attrName) { return element.getAttribute(watch.attrName) || ; } return (element.innerText || element.value || ).trim(); }提取完原始值后再进入归一化阶段。下面这个函数只处理了几类常见噪音示意意义大于直接照搬function normalize(raw) { return raw .replace(/\u00a0/g, ) .replace(/\u200b/g, ) .replace(/\s/g, ) .trim(); }归一化时要注意不要想一次性把所有可能的噪音都去掉。比如把日期统一成固定文本、把数字全部去掉都可能在“识别真实变化”时帮倒忙。理想做法是每个监控任务可以配置自己的归一化规则。4.3 瞬时闪烁造成的假变化用“二次确认”解决有些网站内容在用户操作时会短暂变化比如“库存紧张”在几秒内变成“已售罄”随后又恢复。这种情况下第一次变化是真实的瞬时事件但如果监控任务的目标是“最终稳定状态”就不应该在瞬时变化时立刻通知。更稳妥的做法是引入两阶段确认。大致逻辑如下当前内容和lastStableHash不同把内容记为pendingHash。下一次采集时如果内容仍然是pendingHash说明变化持续存在于是更新lastStableHash并发送通知。如果下一次采集时内容回到lastStableHash则清空pendingHash不通知。它不能解决所有问题因为两次采集之间的瞬态变化仍然可能被漏掉但能明显减少“只出现几秒钟”的假变化。监控频率越密这一机制越有价值。5. 调度、状态保存与通知重试要一起设计5.1 定时精度与频率怎么选最小原型用命令行手工执行只适合验证逻辑。实际使用需要定时任务驱动常见选择是node-cronimport cron from node-cron; import { runAll } from ./collector.mjs; console.log(监控任务已启动每 5 分钟执行一次); cron.schedule(*/5 * * * *, () { runAll().catch((error) { console.error(scheduler error:, error); }); });如果写成这样的定时任务前面collector.mjs底部的那次直接调用就要去掉或者改成只有通过命令行单独执行时才触发。否则导入模块时也会立刻执行一次全量采集。监控频率的选择要区分场景。学习实验环境可以设置很短间隔比如 1 分钟。生产环境需要考虑三件事页面变化本身的时效性要求新闻、库存类可以高频文档版本类一天一次也能接受。目标服务的压力频率过高会给别人网站带去不必要的流量。通知噪音频率越高越容易把中间态当作最终态。5.2 状态文件要保证安全和可回滚Demo 里的watches.json是“配置 状态”放在同一个文件里。这样做的好处是文件少、逻辑简单坏处是不够健壮。真实项目建议至少把下面这些字段分开保存状态字段意义lastHash最近一次已确认内容指纹lastCheckedAt最近一次成功检查时间lastChangedAt最近一次确认变化时间failureCount连续失败次数用于告警和熔断当一个监控任务连续失败时不应该立刻把它标记为“内容变化”更不能让失败状态影响lastHash。如果因为页面超