二级域名与主域名区别：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9ae55d0b7aed.html
📄
二级域名与主域名区别：多层缓存返回不同版本时怎样定位一致性问题
先给结论：当同一路径在二级域名与主域名上返回不同版本时，不要先改缓存配置，而应先用一个带版本标识的请求穿过每一层，记录每层返回的版本号和缓存命中状态，找出第一处版本分叉的层。二级域名与主域名区别在这个场景里不是权重或收录问题，而是缓存键、回源目标和清除范围是否共用同一套规则的问题。
下面用一个明确标注为假设的情境串联决策过程。假设某站点主域名 www.example.com 承载现行内容，旧业务迁到 legacy.example.com，两者共用一套 CDN 和反向代理，页面里带一个版本号注释。运维发现主域名返回 v12，二级域名返回 v9，且刷新后仍不稳定。这个情境只用于说明比较方法，不代表任何真实项目结果。
先确认差异是版本分叉，还是缓存键不同
多层缓存里出现不同版本，常见原因不是某一层坏了，而是各层用了不同的缓存键。缓存键可能包含主机名、路径、查询串、Cookie、语言头或设备类型。主域名和二级域名即便路径相同，只要主机名进入缓存键，就会被当成两个独立对象分别缓存。
要区分这两种情况，可以发一个带唯一查询串的请求，例如 ?probe=20240601a，分别请求主域名和二级域名，并记录响应头里的版本标识、缓存命中状态和回源标记。如果两边都回源且版本一致，说明差异来自缓存键隔离；如果回源后仍不一致，说明源站或中间层按主机名做了不同处理。
这一步的实际动作是记录每层的版本号和命中状态。结果会直接决定下一步：缓存键隔离就统一键规则或接受分离；回源仍不一致就要继续往源站查。
逐层定位第一处版本分叉
多层缓存通常包括浏览器缓存、CDN 边缘、反向代理或应用缓存、源站。定位时不要一次清空所有缓存，否则会丢失证据。按从外到内的顺序逐层探测，每层只改变一个变量。
- 用无缓存请求头请求主域名，记录版本。
- 用同样请求头请求二级域名，记录版本。
- 若两者不同，绕过 CDN 直连反向代理，再比较一次。
- 若仍不同，绕过反向代理直连源站，比较源站返回。
第一处出现版本不一致的层，就是分叉点。分叉点之上是传播问题，之下是生成或存储问题。这个判断比反复刷新页面可靠，因为刷新只能看到最外层结果。
需要提醒的是，请求量、抓取量或某个缓存命中统计归零，都不能单独证明处理正确。命中率下降也可能来自请求头变化、探测流量占比升高或缓存被批量清除，需要结合版本记录一起看。
二级域名与主域名区别如何影响清除范围
很多缓存清除接口按主机名或缓存键操作。如果主域名和二级域名共用一套缓存键规则，清除主域名可能同时影响二级域名；如果主机名进入键，清除主域名就不会动二级域名。差异不在域名层级本身，而在缓存键是否包含主机名。
假设情境里，运维只清除了主域名缓存，二级域名仍返回 v9，这不能证明二级域名缓存“有问题”，只能说明清除范围没有覆盖它。此时应核对清除请求的主机名参数和缓存键构成，而不是继续加大清除频率。
一个可操作的做法是：先为主域名和二级域名各发一次带版本标识的探测请求，保存响应头；再执行一次只针对主域名的清除；然后重发两个探测请求。如果只有主域名版本更新，说明两者缓存键相互独立；如果两者同时更新，说明清除范围是共用的。这个结果决定后续是分别清除还是统一清除。
退出旧内容时保留什么、隔离什么
旧内容、旧系统或旧合作关系退出时，常见做法是把旧路径整体迁到二级域名。但缓存一致性要求先分清哪些部分还需要保留。保留的部分应继续参与版本核对，退出的部分应明确停止回源或返回固定状态。
可以用一个假设清单来决策：
- 仍被引用的静态资源：保留在二级域名，并确保缓存键与主域名规则一致，避免同一文件两个版本。
- 仅剩历史价值的页面：保留可访问，但不参与主域名的缓存清除流程，减少误清。
- 已确认退出的接口：返回明确状态，避免缓存继续保存旧响应。
这里要注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。缓存一致性和索引状态是两条线，不要用其中一条的结果推断另一条。
把定位结果转成下一步动作
定位到第一处分叉后，下一步动作取决于分叉层：
- 若分叉在 CDN 边缘，核对缓存键是否包含主机名，并确认清除请求覆盖了二级域名。
- 若分叉在反向代理，检查代理是否按主机名走了不同上游或不同缓存区。
- 若分叉在源站，检查应用是否按 Host 头生成了不同版本或读取了不同数据源。
每完成一步，重发同一组探测请求并记录版本。只有版本记录显示两层一致，才进入下一步。若某一步后版本仍不一致，不要继续清缓存，而应回到该层检查键规则和回源目标。
最后要说明适用条件：这套方法适合主域名和二级域名共用缓存设施、且能观察到响应头版本标识的场景。如果无法看到缓存命中状态或版本标识，应先补上可观测性，再谈定位。不同搜索引擎和缓存服务对缓存键、清除接口的支持情况须分别核查，不能把一层的结论直接套到另一层。
