网站缓存：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6bfd521902a8.html
📄
网站缓存：入口页面正常但深层链路失效时怎样定位断点
先给结论：当入口页正常而深层链路失效时，优先怀疑缓存键在链路中途发生变化，而不是先怀疑源站宕机。判断条件很具体——入口页与深层页共用同一份缓存配置模板，但深层页的URL带路径参数、查询串或Cookie分支。反例也很明确：如果深层页的失效表现为“首次请求正常、后续请求异常”，那问题更可能出在回源后的缓存写入，而不是缓存键匹配，此时按缓存键排查会浪费一轮验证。
先分清两类断点：键不匹配与回源失败
深层链路失效通常落在两种断点上，两者的证据不同，处理顺序也不同。
- 缓存键不匹配：入口页命中缓存，深层页每次都被当成新对象。表现是深层页响应头里缓存命中标记缺失或反复变化，回源次数在日志里持续偏高。原因是深层URL携带了入口页没有的参数、路径层级或设备分支，缓存层按完整URL或参数集合生成键，导致深层页无法复用入口页的缓存对象。
- 回源后写入失败：深层页首次能取到源站内容，但缓存层没有成功保存，后续请求继续回源。表现是同一深层URL在短时间内多次触发回源，且响应内容一致。原因是响应头里的缓存指令被源站或中间层覆盖，或缓存层对响应体大小、状态码有写入限制。
区分方法：对同一个深层URL连续请求两次，比较两次的响应头与回源日志。若两次都回源且内容相同，偏向写入失败；若第一次回源、第二次仍回源但入口页始终命中，偏向键不匹配。
两种做法的取舍：先改缓存键还是先改回源头
这里存在一个真实的取舍，选择取决于深层页的流量结构。
选择一：先调整缓存键。适用条件是深层页URL参数多、且参数中大部分对内容无影响。代价是缓存键放宽后，可能把本应区分的内容合并，造成不同用户看到同一份缓存。动作是先在缓存层把无影响参数加入忽略列表，再对一组深层URL验证命中标记。若命中标记出现且内容与源站一致，说明断点在键；若命中标记出现但内容错位，说明忽略列表放得过宽，需要回退并收窄。
选择二：先修正回源头。适用条件是深层页URL干净、参数少，但响应头里缓存指令被覆盖。代价是修改回源头可能影响入口页已有的缓存行为。动作是只对深层路径单独设置缓存指令，观察回源次数是否下降。若下降，说明断点在写入；若不变，说明缓存层根本没把深层路径纳入缓存范围，需要回到键的排查。
两种做法没有绝对优劣。流量集中在少数深层页时，先修回源头见效更快；深层页数量多且参数杂乱时，先收缓存键更省后续维护。
一个假设例子：用两次请求定位断点
假设某站点入口页 / 始终命中缓存，深层页 /list?page=2&from=home 每次回源。第一步，对深层页连续请求两次，记录回源次数与响应头。若两次都回源，排除“首次未缓存”的解释。第二步，把 from=home 从请求中移除，只请求 /list?page=2。若此时命中，说明 from 参数参与了缓存键，断点在键；若仍不命中，说明该路径未被缓存层覆盖，断点在缓存范围配置。这个例子的数字仅用于说明比较方法，不代表任何实际站点的表现。
需要提醒的是，抓取量或回源量归零不能单独证明处理正确。它也可能是抓取被限制、请求被拦截或日志采集中断造成的。要确认断点已修复，应同时看命中标记、内容一致性和回源日志三个来源。
下一步动作与验收条件
定位到断点后，下一步动作取决于断点类型。若断点在缓存键，动作是收窄参与键的参数集合，验收条件是深层页出现命中标记且内容与源站一致。若断点在回源写入，动作是修正深层路径的缓存指令，验收条件是同一深层URL在短时间内不再重复回源。若两者都未命中，动作是把深层路径单独加入缓存范围，再重复上述验证。
如果深层链路涉及登录态或个性化内容，缓存本身可能不适合覆盖该路径，此时应改为确认该路径是否被错误纳入公共缓存，而不是继续追求命中。这一步的判断依据是内容是否因用户而异，而不是命中率高低。
