电商价格监测：浏览器层
把价格监测负载拆成调度、浏览器与变更检测三层，并固定语言、货币、区域和渲染时机，使一次价格差异只有一个原因。
BotBrowser Team
电商价格监测所用的浏览器是流水线中的一个阶段，不是流水线本身。一次记录下来的价格可能与上一轮不同：页面以另一种货币渲染，读取发生在价格元素稳定之前，请求从另一个区域出口，或者零售商确实改动了那个数字。其中只有第四种属于数据事实，其余三种是浏览器层要么避免、要么在无声中引入的测量缺陷，包括线路从操作方并未打算使用的区域出口这一情形。BotBrowser 提供可配置的 Chromium 运行时，从操作方提供的配置启动并返回渲染后的页面，因此浏览器阶段可以被固定，而其它阶段分别测量。它不能调度任务、不保存历史、不计算差异、不判断零售商是否允许采集，也不保证页面显示哪个价格。这套流程假定使用自有 fixture 或明确获授权的目标，不提供规避零售商保护措施的任何方法。
TL;DR
- 把流水线写成四个阶段，每个阶段只有一个负责人：调度、浏览器渲染、提取、变更检测。只有在每次观测旁记录阶段边界，价格差异才可能被归因。
- 比较两次运行之前，先固定三个浏览器可见输入：
Accept-Language加navigator.languages、用于格式化的货币、出口区域。第一次观测时也要清空或固定 cookie 与已存偏好，因为已存偏好可能覆盖这三项。其中任何一项改变，同一个商品都会渲染出不同的数字。 - 用有名字的就绪条件取代“等价格出现”，例如价格节点非空、其文本能按数字解析、且周边报价块完整。固定 sleep 不是就绪条件。
- 金额以整数最小单位存储，旁边放 ISO 4217 货币代码。浮点数
19.99会丢掉差异所依赖的分位边界，而¥1,980与$19.80不是同一个量。 - 每次观测归入四类之一：观测到价格、价格缺失、请求被拒、页面未稳定。把这四种合并成“没有价格”，正是让监测流水线看起来准确、实际不准确的缺陷。
目录
将监测负载拆成四个阶段
一个价格监测任务，对每个商品、每一轮只回答一个问题：这一时刻、这一货币、这一区域，这个页面显示了什么数字？流水线中的其它部分存在，都是为了让这个答案能与上一个答案比较。把工作拆成阶段，差异才可解释，因为每个阶段都可能以其它阶段不会的方式失败。
| 阶段 | 负责 | 可能产生的失败 | 无法修复 |
|---|---|---|---|
| 调度 | 哪个商品、多久一次、哪个时间槽、重试预算 | 错过时间槽、运行重叠、重复观测 | 错误或过期的读取 |
| 浏览器渲染 | 语言环境、货币、出口区域、就绪条件 | 错误货币读取、错误区域价格、过期读取 | 已改变的价格 |
| 提取 | 哪个节点、哪个解析器、哪个回退 | 解析错误、单位错误、字段错误 | 始终未稳定的页面 |
| 变更检测 | 基线、容差、告警规则 | 误告警、漏告警、漂移 | 一次糟糕的观测 |
这张表是诊断工具，不是组织架构图。差异出现时，第一个问题是两个观测分别由哪个阶段产生，因为用两套不同浏览器配置算出的差异不是价格变化。一条报告“价格变了”却不记录两次观测各自货币、区域和就绪条件的流水线，给出的是无法验证的主张。
为什么阶段边界必须逐次观测记录
每个任务只存一次配置并不够。一个任务在批次中途改变货币设置，或在代理错误后切换到另一个区域的路由，会产生彼此不可比较的观测，即便任务标识符相同。有效配置要记在每次观测旁，而不是每次运行旁。
逐次观测值得记录的字段数量少且稳定：浏览器构建标识、profile 标识、有效 Accept-Language、提取所用货币代码、路由报告的出口区域、就绪条件名称、读取时间戳、文档响应的 HTTP 状态。有了这八个字段，两次观测可以比较，或被明确声明为不可比较。没有它们，差异只是一种意见。
浏览器阶段能报告什么、不能报告什么
浏览器能报告它渲染了什么：节点的文本内容、节点上存在的属性、文档的 HTTP 状态、服务器发回的响应头，以及所选就绪条件何时成立。它也能报告文档及其子资源的请求时序。
浏览器不能报告一个数字为何如此。它无法判断 1,299 是显示货币的 1,299 个单位，还是一个取整后的区域价格；无法判断零售商是否对另一个账户应用了会员折扣；也无法判断两次运行之间促销是否结束。它同样无法报告一个从未收到的页面本来会显示什么价格。这些是提取与业务问题，把它们归到浏览器阶段会产生错误的修复方向：把每次价格差异都当成浏览器问题的团队，可能在真正原因是货币默认值时轮换 profile。
一个商品，一个比较单元
在写任何流水线代码之前，先决定跨运行什么算同一个商品。零售商商品标识在不同区域并不稳定：同一件商品在不同店面可能携带不同标识，区域目录还可能列出全球目录没有的变体。用一个稳定的操作方侧键作为比较单元，并把零售商自己的标识作为属性存在旁边。
如果操作方侧键由 URL 构造，先归一化：去掉跟踪参数，按店面规则统一路径大小写，丢弃会话片段。仅相差一个活动参数的 URL 指向同一商品，当成两个商品会把观测数量翻倍而不增加信息。
固定浏览器侧变量
请求路径上有四个表面会在零售商毫无变化的情况下改变页面显示的数字。其中三个在浏览器内部设定：页面协商到的语言、店面选择的货币，以及跨请求保留的偏好或 cookie 状态。第四个是线路出口区域，它属于路由层，只能从线路侧观测，无法从页面读取。它们彼此独立，失败方式各不相同。
语言协商及其解析链
店面通常按站点自选的顺序从文档请求的 Accept-Language、URL 路径或子域片段、cookie 或已存偏好、出口区域中选择语言。页面内部，navigator.language 与 navigator.languages 描述浏览器上报的内容，Intl 格式化按语言标签解析。
这是四个独立表面，可能彼此不一致。请求发送 Accept-Language: de-DE 而 navigator.languages 报告 en-US 时，可能得到德语页面，客户端格式化却仍按英文渲染数字。可观察结果是页面看起来已本地化，金额却按另一套约定格式化，正是这种混合状态制造幽灵价格差异。
| 表面 | 由谁设置 | 从哪里可观测 | 漂移时的典型缺陷 |
|---|---|---|---|
Accept-Language 请求头 | 自动化库的上下文选项 | 捕获的请求头 | 服务器选择另一种店铺语言 |
navigator.language / navigator.languages | 浏览器 profile | 页面上的 page.evaluate | 客户端 Intl 输出改变 |
| URL 路径或子域 | 请求的地址 | 最终 URL | 请求到达完全不同的店铺 |
| 存储的偏好或 cookie | 先前导航或同意流程 | 文档 cookie、存储 | 首次请求与后续请求不一致 |
可行的规则是把四个表面固定到同一组值，并在一次运行的首个观测上验证一致性。Playwright 为 locale 和 timezone 暴露上下文选项，请求头与 navigator 值能在同一次启动中对齐，page.evaluate 可以在任何提取之前读回页面实际看到的内容。
货币选择与格式化
货币是监测流水线中无声错误的常见来源，因为价格元素通常包含格式化字符串，而不是机器可读数字。$1,299、1.299 €、¥1,299、1 299,00 € 可能代表不同数量，也可能是同一数量在不同约定下的渲染。把符号与数字分开还不够：同一个字形会被多种货币使用。
存储记录里使用 ISO 4217 代码，永不用符号。USD、EUR、GBP、JPY、CNY 没有歧义；$ 有歧义，¥ 同时用于 JPY 和 CNY。页面暴露机器可读货币时优先使用它：schema.org Offer 带有 priceCurrency 与 price，JSON-LD 块比渲染标签更可靠地解析。
最小单位出于同样理由重要。多数货币使用两位小数，JPY 和 KRW 使用零位，KWD 和 BHD 等货币使用三位。把每个解析出的价格乘以 100 得到整数分值的流水线，会把零位小数货币错放两个数量级。存储 ISO 4217 代码、该代码的最小单位指数、整数金额，再依据这三个字段格式化显示。
取整行为也要记录。货币样式的 Intl.NumberFormat 默认按该货币的默认小数位取整，页面把 1.995 显示为 2.00 时，信息在提取看到之前已被丢弃。比较需要第三位小数时，提取必须读取未格式化的值，或接受流水线比较的是已取整价格。
区域来自路由，不来自浏览器
区域是团队最常以为自己控制、实际并不控制的输入。浏览器能报告时区和一组语言标签，profile 能声明地理位置，但店面依据它可观察到的请求决定区域目录，其中出口地址占主导。profile 声明一个区域而路由从另一个区域出口时，页面的区域目录与客户端格式化会彼此矛盾。
要有意对齐。负载需要德国店面时，路由应从德国地址出口，Accept-Language 应携带德语，上下文 locale 应是德语标签，时区应是德国访客会看到的那个。对齐是运行的一项配置属性，并且可验证：最终 URL、文档的 Content-Language 响应头（存在时）、渲染出的货币，三者共同说明哪个店面作出了应答。
| 检查项 | 证明什么 | 从哪里读取 |
|---|---|---|
| 重定向后的最终 URL | 哪个店铺路径作出应答 | page.url() |
Content-Language 响应头 | 服务器选择了哪种语言 | 捕获的文档响应 |
| 渲染出的货币代码 | 页面取自哪个目录 | Offer.priceCurrency 或价格节点 |
Intl.DateTimeFormat().resolvedOptions().timeZone | 页面看到哪个时区 | page.evaluate |
| 路由出口区域 | 请求来自哪个区域 | 路由自身的报告，不是页面 |
最后一行无法从页面读取，因此必须由拥有路由的层记录。页面可以完美渲染，同时路由从操作方并不打算使用的区域出口，而 DOM 中没有任何线索暴露这一点。价格记录需要随附哪些字段、以及每个零售商与区域各用一个上下文的布局，见电商监控中的指纹保护；为固定比较窗口锁定区域、语言与线路，见用于 SEO 监控的浏览器 profile。
一份固定配置记录
把固定值放进一份记录，供提取阶段与变更检测阶段共同读取。可用的形状是一个小对象：语言标签、货币代码与最小单位指数、区域、时区、就绪条件名称、浏览器与 profile 标识。这份记录随观测一起移动。
两条约束适用。第一，记录描述有效配置，不是请求配置；请求 de-DE 却被站点重定向到英文店面时，必须记录实际应答的那个。第二，配置变化是流水线事件，不是例行编辑：货币设置一旦变化，变化两侧的观测不可比较，变更检测阶段需要知道这一点，而不是收到一个差异。
定义渲染时机与过期读取
价格节点经常在正确之前就已经存在。服务器渲染的占位符、骨架元素、客户端水合步骤、改写显示数字的促销横幅，都可能在同一次页面加载中依次出现。在错误时刻读取，会得到一个确实出现在页面上、却从来不是价格的数字。
以就绪条件取代 sleep
把就绪条件写成页面上的谓词，而不是经过的时间。有用的谓词包含三部分：价格节点存在；其文本按声明的货币规则能解析为数字；一个结构证据确认周边报价块完整，例如存在 priceCurrency 值、库存或可售标记、或处于可用状态的加入购物车控件。
第三部分把真实读取与碰巧读取分开。页面可能在报价块组装完成之前很久就暴露一个带数字字符串的价格节点，只检查节点的谓词会在部分渲染上通过。等待完整证据集会多花一点延迟，却移除一整类过期读取。
Playwright 直接提供这些原语：page.waitForFunction 能在页面中求值谓词，page.waitForSelector 能以节点存在为门，page.waitForResponse 能在价格通过网络而非文档到达时以特定 API 响应为门。在它们之间选择，是判断价格来自何处，这个选择要进入运行记录，因为它改变了“就绪”的含义。
| 价格来源 | 就绪原语 | 证明什么 | 残余风险 |
|---|---|---|---|
| 服务器渲染文档 | 价格节点加结构证据上的 waitForSelector | 文档包含该报价 | 后续脚本改写数字 |
| 客户端水合节点 | 完整谓词上的 waitForFunction | 客户端完成报价组装 | 后续促销脚本改变它 |
| 由 API 调用交付的价格 | 匹配端点的 waitForResponse | 价格响应已到达 | DOM 尚未更新 |
| 交互之后的价格 | 脚本化交互后接谓词 | 交互已完成 | 交互选错了 |
第四行是监测流水线可能悄悄破坏自身边界的地方：揭示会员价或区域价的交互属于已认证或个性化状态，仅获授权访问公开页面的负载应把这种观测归为超出范围，而不是提取它。
过期读取、缺失价格与被拒请求
只存一个数字或 null 的流水线看来，这三种结果完全相同，它们却要求不同响应。过期读取意味着就绪条件错了，观测应当丢弃而不是存储。价格缺失意味着页面已完整渲染，报价块中确实没有价格，这是关于商品的真实发现。请求被拒意味着浏览器从未收到页面，属于访问问题，完全不是数据问题。
要显式分类。每次观测存一个结果代码：observed、absent、refused、unsettled。下游只有 observed 进入价格差异计算，absent 进入目录变化信号，refused 进入访问日志，unsettled 进入就绪条件缺陷计数。把四者都当作“没有价格”的流水线，会在系统性读取失败的同时报告目录稳定。
条件请求与 304 的含义
负载重读一个见过的页面时，服务器可能对携带上一轮 ETag 的 If-None-Match、或携带上一轮 Last-Modified 的 If-Modified-Since 条件请求回答 304 Not Modified。304 不是失败，也不是一次新鲜观测：它表示服务器本会发送的表示，与验证器所描述的那一份相比没有变化。
对价格监测而言，304 同时是有用证据和陷阱。它有用，因为确认文档自验证器签发以来未变。它是陷阱，因为验证器描述文档，不描述价格：由独立 API 调用获取并在客户端注入的价格可以变化，而文档的 ETag 保持不变。价格经网络到达时，要作为条件依据的是那个响应上的验证器，而不是文档上的。
Vary 让同一个问题更复杂。响应携带 Vary: Accept-Language 表示缓存表示以该请求头为键，改变语言设置的运行不会重读同一条缓存条目。把 Vary 响应头记在观测旁，可以防止后续分析假定两次观测共享缓存键，而实际并未共享。
时钟、时间戳与顺序
用同一个时钟记录观测时间，响应提供服务器自己的时间信号时（例如 Date 响应头）把它记在旁边。页面的 Date.now() 与主机时钟可能不同，混用两者的流水线会产生顺序不可信的观测。
顺序比精度更重要。同一商品的两次观测若存储时间颠倒了真实先后，变更检测阶段会报告方向错误的价格变化，甚至据此告警。除墙上时钟时间之外，每轮再记录一个单调递增的序号，即使两个时间戳相撞，顺序仍可恢复。
区分浏览器错误与数据错误
四阶段拆分的作用，是把“价格看起来不对”变成具体、可核查的主张。先以阶段边界做第一层分类，再以观测结果代码做第二层。
失败归因矩阵
| 症状 | 最可能的阶段 | 第一项检查 | 不要做 |
|---|---|---|---|
| 某个区域的所有商品显示不同货币 | 浏览器渲染 | 运行记录中的有效货币与出口区域 | 轮换 profile |
| 单个商品价格变动后又变回 | 变更检测 | 容差与告警规则 | 重写提取器 |
| 一部分商品价格缺失 | 提取 | 报价块是否根本不含价格 | 用新 profile 重试 |
| 运行以固定间隔出现空档 | 调度 | 时间槽重叠与重试预算 | 提高并发 |
| 价格持续落后一步 | 浏览器渲染 | 就绪条件与过期读取计数 | 归咎于零售商 |
| 价格差了 100 倍 | 提取 | 该货币代码的最小单位指数 | 调整告警规则 |
“不要做”一列是运维要点。这些症状各有一个诱人的修复动作，却作用在另一个阶段上，执行后会把可诊断的缺陷变成永久且无从解释的偏移。
支持分类的运行记录
记录要小到确实会被写入，又要完整到不必重跑任何东西就能套用上面的矩阵。可用的逐次观测形状携带：商品键、观测时间与序号、结果代码、原始价格文本、解析出的整数金额、ISO 4217 代码与最小单位指数、有效语言与区域、就绪条件名称、文档 HTTP 状态、最终 URL。
两个派生字段让矩阵在规模上可用：每轮过期读取计数，以及分阶段失败计数。前者是谓词通过但证据集不完整的观测数量，调优后应为零。后者按阶段归组结果代码，使上升的 refused 计数清楚显示为访问问题，上升的 unsettled 计数清楚显示为就绪问题。
运行前检查清单
- 比较单元是操作方侧商品键，零售商标识作为属性存储。
- 语言各表面一致：请求头、
navigator.languages、URL 路径、任何已存偏好。 - 货币以 ISO 4217 代码加最小单位指数存储，从不用符号。
- 出口区域由路由层记录，并与目标店面一致。
- 就绪条件是有名字、带证据集的谓词，不是固定 sleep。
- 每次观测带一个结果代码：
observed、absent、refused、unsettled。 - 条件请求验证器绑定到实际携带价格的那个响应。
- 变更检测容差在第一条告警之前声明，而不是在第一次误报之后。
- 配置变化作为事件记录，用它切分可比较的观测窗口。
FAQ
浏览器决定页面显示哪个价格吗？
不决定。店面依据自己的目录、促销、账户状态与区域规则决定价格。浏览器层控制店面能从请求中观察到什么，这种观察可以影响返回哪个目录或哪种货币，但数字本身来自零售商的系统。把浏览器当成价格差异的原因，会导致配置反复变动，却始终碰不到真正的变量。
更长的等待是过期读取的可靠修复吗？
它减轻症状而不修复问题。更长的固定等待降低读到部分渲染的概率，同时降低吞吐量，并且页面比所选延迟更慢时仍然失败。命名价格节点及其证据集的就绪谓词会以可见且具体的方式失败，这正是监测流水线需要的：一条写着“未稳定”的观测可用，而一条无声捕获占位符的观测不可用。
价格应存为浮点数还是整数？
存最小单位整数，金额旁边放 ISO 4217 代码及其指数。二进制浮点无法精确表示多数十进制小数，存储的 19.99 并不精确等于十九又九十九百分之一，对这类值反复运算会累积误差。整数最小单位让相等与差值精确，指数则防止零位小数货币被当作有分位来缩放。
实践结论
从阶段边界开始，而不是从浏览器配置开始。写下四个阶段，为每个阶段命名负责人，把有效浏览器侧配置记在每次观测旁，而不是每个任务旁。然后用同时命名价格节点与结构证据的就绪谓词取代 sleep，并把每次观测归入四个结果代码之一：observed、absent、refused、unsettled。
下一步很小：在获授权页面上取一个商品，在固定配置下记录两次价格，确认两次观测携带相同的货币代码、区域、就绪条件和结果代码。若相同，流水线就能归因未来的差异。若不同，差异已经存在，浏览器层是第一处需要查看的地方。
Sources
本文属于指南： 代理配置总览：浏览器网络决策图