网站缓存，部分页面正常而特定参数异常时怎样缩小复现条件
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /02eb0a03bca0.html
📄
网站缓存，部分页面正常而特定参数异常时怎样缩小复现条件
先给一个有条件结论：当同一路径在无参数或普通参数下正常、只在特定参数组合下异常时，优先怀疑缓存键没有覆盖全部影响输出的输入，而不是先怀疑源站整体故障。这个结论成立的前提是：异常可稳定复现，且你能拿到同一路径在正常与异常两种请求下的响应头、状态码和正文片段。反例是：如果异常只在某个浏览器或某个网络出口出现，换用命令行请求同一参数却始终正常，那么问题更可能在客户端或中间网络，而不是缓存键设计，此时继续改缓存规则会掩盖真正原因。
先固定一组可核对的请求事实
把分歧转成可核对的项目的做法，是让每个角色提交同一格式的请求记录，而不是各自描述“我这里坏了”。记录至少包含：完整路径与查询串、请求方法、关键请求头、响应状态码、响应中与缓存相关的头、正文中一处可识别的稳定片段。多个角色对同一事实理解不同，往往是因为有人看的是浏览器地址栏，有人看的是抓包结果，有人看的是日志里的规范化路径。统一记录格式后，差异会从“谁说得对”变成“哪一项输入不同”。
实际动作：先让异常方和正常方各提供三条记录，覆盖正常、异常、以及两者之间只差一个参数的请求。结果如何影响下一步：如果三条记录里只有查询串不同，就可以把变量收敛到参数本身；如果发现请求头也不同，就要先把头变量分离，否则无法判断是参数还是头触发了异常。
把参数分成会改变输出和只做追踪两类
特定参数异常，常见原因是缓存键只包含路径，而参数实际改变了页面输出。可以先用一个假设例子说明比较方法：假设 /list?page=2 正常，/list?page=2&sort=price 异常。这里 sort 明显会改变列表顺序，属于会改变输出的参数；而 utm_source 这类通常只用于追踪，不应改变正文。把参数按这两类分开后，再看异常参数落在哪一类。
- 会改变输出的参数：分页、排序、筛选、语言、币种、登录态相关标识。它们若未进入缓存键，容易让一个变体命中另一个变体的缓存。
- 只做追踪的参数：活动来源、点击标识。它们若进入缓存键，容易造成大量重复缓存对象；若不进入缓存键，通常不应导致正文异常。
- 边界参数：空值、重复出现、大小写不同、编码不同。它们常被忽略，却可能让缓存键计算与源站解析结果不一致。
动作与结果：把异常参数逐个剥离，每次只保留一个，观察异常是否仍出现。如果剥离到只剩追踪参数时异常消失，下一步应检查缓存键是否错误地把追踪参数纳入了变体，或源站是否对追踪参数做了重定向。如果剥离到只剩会改变输出的参数时异常仍在，下一步应检查该参数是否被缓存键覆盖。
用响应头判断是命中旧内容还是回源出错
缩小复现条件时，不要只看页面表现。响应头能区分两种常见情况：一是命中了不属于该参数的缓存对象，二是回源本身返回了异常内容。若响应显示命中缓存，且正文与另一个参数的结果一致，说明缓存键覆盖不足；若响应显示回源，且状态码或正文异常，说明问题在源站处理参数时已经发生。两种情况的下一步动作不同：前者要调整缓存键或清理受影响对象，后者要先修源站参数处理。
这里有一个容易误判的点：请求量、抓取量或某项统计归零，不能单独证明缓存处理正确。它还可能来自流量本身下降、采集口径变化、日志延迟或过滤规则调整。因此，判断缓存是否修好，应回到同一组参数请求的响应一致性，而不是只看某个统计曲线。
把复现条件写成最小集合再决定下一步
当你能用一句话写出最小复现条件，例如“同一路径下，仅当同时出现排序参数和分页参数时，返回内容与无排序时相同”，就已经把问题从模糊异常变成了可核对项目。此时再决定动作：如果是缓存键未覆盖排序参数，调整键规则后，用同一组请求复测；如果调整后正常请求也发生变化，说明键规则改得过宽，需要回退并重新划分参数类别。
最后注意适用条件：这套缩小复现条件的方法，要求你能控制或至少观察到请求参数与响应头。若异常只发生在你无法观察的中间层，或参数由第三方脚本动态拼接，应先固定可观察的那一段，再逐步向外扩展。每一步动作都应以“能否让正常与异常请求的差异更少”为标准，而不是以某个统计是否变化为标准。
