WordPress主机迁移，多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /34c101a945ef.html
📄
WordPress主机迁移，多层缓存返回不同版本时怎样定位一致性问题
先看差异是否随请求身份变化：同一 URL 在登录态与匿名态、带与不带查询参数、不同地区出口下返回不同内容，通常说明某一层缓存按错误的键做了区分或未区分。定位时不要先清空所有缓存，而应逐层固定输入、记录响应头与正文哈希，确认差异首次出现在哪一层。
先判断是缓存键设计问题还是回源内容问题
如果匿名请求与登录请求拿到不同版本，先检查页面缓存是否把登录 Cookie 纳入了缓存键。若未纳入，登录用户可能看到匿名缓存副本；若纳入过度，同一篇文章会为每个会话生成独立副本，命中率骤降但一致性反而正常。两种情况的证据不同：前者表现为登录态内容被匿名版本覆盖，后者表现为缓存条目数量异常膨胀。
判断依据是响应头中的缓存命中标识与 Age 值。若同一 URL 在两次匿名请求中 Age 持续增长而正文哈希不变，说明边缘层在正常复用；若 Age 归零且正文哈希变化，需继续向上游查找。此时不要仅凭抓取量或请求量下降判断问题已解决，那可能只是缓存全部未命中导致的假象。
两种取舍：统一缓存键，还是按层隔离缓存
选择取决于站点是否依赖按用户或按地区变化的动态内容。
- 统一缓存键：适用于内容对多数访客一致、仅少量个性化区块的站点。动作是把 Cookie、语言、设备等变量收敛为白名单，个性化部分改为客户端异步加载。代价是个性化区块首屏可能闪烁，且需要确认异步接口本身不被缓存。
- 按层隔离缓存：适用于会员、多地区定价等必须服务端区分的内容。动作是让边缘层只缓存静态资源，页面层按明确维度分键，并在响应头中标注变体来源。代价是缓存条目增多、回源压力上升，需要监控存储与命中率。
若两种做法都看似合理，优先选统一缓存键，除非个性化内容涉及价格、权限或合规信息。涉及这些内容时，错误复用版本的代价高于回源成本。
用固定输入逐层比对，确定差异出现的位置
准备一组固定请求：同一 URL、同一 User-Agent、同一 Cookie 状态，分别直连源站、绕过边缘层、经过完整链路。对每次响应记录状态码、关键响应头与正文哈希。假设某篇文章在直连源站时哈希为 A，经过边缘层后匿名请求哈希变为 B，而登录请求仍为 A，则差异最可能出在边缘层的缓存键或页面缓存规则，而非数据库或主题渲染。
这一步的实际动作是先固定一组请求并记录基线，再逐层启用缓存。结果会直接决定下一步：若差异只在启用某一层后出现，就集中检查该层的键规则；若所有层都返回同一哈希，则问题可能来自客户端或 CDN 之外的中间代理。
排查顺序与常见例外
- 确认源站本身对同一输入返回稳定结果，排除主题或插件按随机数、时间戳输出。
- 检查页面缓存插件的排除规则是否与边缘缓存规则冲突，例如插件已排除的 URL 被边缘层重新缓存。
- 检查查询参数处理：部分层忽略全部参数，部分层只忽略特定营销参数，导致同一路径映射到不同变体。
- 检查清除机制：发布更新后只清除了页面层而未清除边缘层，旧版本会继续返回。
例外情况包括：站点使用 ESI 或边缘包含拼装页面，此时整页哈希本就不应一致，应改为比对各片段；以及源站开启了按地理位置的跳转，此时不同出口 IP 返回不同重定向属于预期行为。遇到这些例外，先确认架构设计，再判断是否为故障。
确认一致后仍需验证的边界
当各层返回同一版本后，还需验证缓存清除是否覆盖全部变体。动作是发布一次测试更新，分别以匿名、登录和带参数请求检查旧版本是否仍可访问。若旧版本仍存在，说明清除规则未覆盖该变体，需要补充清除条件而非扩大清除范围。清除范围过大虽能暂时消除差异，但会持续拉高回源，掩盖真正的键设计问题。
另外，robots.txt 的抓取限制不等于索引移除，缓存层返回一致也不代表搜索引擎看到的就是同一版本，二者需要分别核查。只有在确认各层键规则、清除规则和变体边界都符合预期后，才能把该问题视为已定位。
