特殊后缀域名，功能开关导致页面变化时怎样记录版本状态
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /a6f44b0bc1d5.html
📄
特殊后缀域名，功能开关导致页面变化时怎样记录版本状态
功能开关改变页面时，真正要记录的不是“页面变了”，而是“哪个版本对哪类访问者生效、生效持续了多久、原始输出是否还能复现”。如果只截一张改后页面图，后续既无法判断某次抓取看到的是开关开启前还是开启后的状态，也无法解释同一URL在不同时间返回不同内容的现象。对特殊后缀域名，这个问题更突出：后缀本身不决定抓取或索引行为，但注册局、DNS、CDN与应用的配置层往往更多，开关状态与域名解析状态容易混在一起，记录时必须把两者分开。
同一个URL出现两种页面，先分清是开关切换还是缓存分层
假设一个使用特殊后缀的站点，对登录用户和未登录访客显示不同模块，开关按访客类型分流。此时同一URL可能返回两套HTML：访客版本和登录版本。看到抓取工具拿到访客版本、而人工浏览器看到登录版本，有两种合理解释。
- 解释一：功能开关按请求特征分流。开关读取Cookie、请求头或IP段，不同请求自然得到不同输出。这种情况下，页面变化是应用层主动决策的结果。
- 解释二：缓存层保留了旧版本。CDN或反向代理按URL缓存了开关开启前的响应，新请求命中旧缓存。这种情况下，页面变化是缓存未失效的结果。
两种解释对应完全不同的处理动作。若是开关分流，要记录的是分流规则和各类访问者看到的版本；若是缓存分层，要记录的是缓存键、失效时间和回源结果。把两者混为一谈，容易在排查时反复切换开关，却始终看不到稳定输出。
能区分两种解释的证据：带条件的请求对比
区分开关分流与缓存分层，最直接的动作是固定一个变量做对照。在开关状态不变的前提下，分别发起两类请求：一类带访客标识（如无Cookie），一类带登录标识，然后比较响应体中的关键模块是否出现、响应头中的缓存命中标记是否变化。如果两类请求返回不同内容，且响应头显示都回源，则更支持开关分流；如果两类请求返回相同旧内容，且响应头显示命中缓存，则更支持缓存分层。
这个动作的结果会直接决定下一步。若确认是缓存分层，下一步应检查缓存键是否包含开关状态或用户分组，而不是继续调整开关逻辑；若确认是开关分流，下一步应记录分流规则的版本，并确认该规则是否对未登录抓取者返回了与预期一致的版本。这里要注明假设：上述判断基于响应头能反映缓存命中情况，若中间层隐藏了该信息，则需要通过回源日志或临时绕过缓存来验证。
版本状态记录应包含哪些字段
只记录“开关开”或“开关关”不够，因为开关状态、代码版本、配置版本和缓存状态是四个独立维度。建议每次变更时记录以下字段，并保证它们能对应到具体时间点。
- 开关标识与取值：开关名称、当前取值、生效范围（全局、按用户组、按地区）。
- 应用版本：提交哈希或构建编号，用于确认页面模板与开关逻辑的对应关系。
- 配置版本：影响该页面的路由、重写、缓存规则所在的配置版本。
- 请求条件：记录观察时使用的请求特征，如是否携带Cookie、User-Agent类型、来源IP段。
- 响应摘要：关键模块是否存在、主要文本片段、响应头中的缓存与变体标记。
其中“请求条件”最容易被省略，但它恰恰是解释同一URL不同输出的关键。没有它，后续无法复现当时的观察结果。
特殊后缀域名下容易混入的额外变量
特殊后缀域名常伴随更复杂的解析和分发链路。例如，域名可能同时接入多个CDN、使用不同的DNS解析策略，或在不同地区解析到不同节点。当开关变化与解析变化同时发生时，页面差异可能来自节点差异而非开关本身。记录版本状态时，应把DNS解析结果和节点标识一并留存，至少记录观察时刻解析到的地址。若发现不同解析结果对应不同页面输出，应先排除节点配置差异，再判断开关是否真正生效。
另一个变量是大小写与路径规范化。部分特殊后缀域名在路径处理上可能与常见后缀存在差异，开关若依赖路径匹配，路径规范化规则的变化会间接改变开关命中结果。记录时保留完整请求URL，而不是只记录域名和路径片段，可以减少这类混淆。
一个可复用的最小记录流程
在开关变更前后各执行一次固定动作：用同一组请求条件抓取目标URL，保存响应体关键片段、响应头和解析地址，并标注开关取值与应用版本。变更后若观察到页面变化，先对比两次记录的请求条件是否一致；若不一致，先统一条件再比较。若条件一致而输出不同，再检查缓存命中与解析节点是否变化。这个流程不能保证一定找到原因，但能把“开关导致变化”从“缓存或节点导致变化”中分离出来，避免把现象直接当成原因。记录的目的不是证明某次变更正确，而是让下一次判断有可复查的依据。
