缓存不生效、刷新不彻底？一次讲清缓存键、URL 参数与 Purge 机制
缓存键：带参数的完整 URL
边缘节点用缓存键定位一份缓存文件，默认缓存键就是请求 URL 的全称——query 参数也算。于是三个经典现象一次解释清楚：
- 同一个文件，v1 与 v2 两个版本号参数，是两份互不相干的缓存；
- 新版本发布后用户还拿到旧文件，多半是页面引用的是不带新版本号的旧 URL；
- 每次访问都拼随机参数的 URL 命中率是 0，但这本来就是正确行为——它们确实是不同资源。
发版的最优解是"只改引用不改文件"：样式表带 ?v=31 这样的版本参数，旧缓存随引用更新自然退役，连刷新都不用点。
哪些 URL 永远旁路
非 GET 或带 Authorization 的请求、未命中任何缓存规则的 URL，一律不进缓存。想要下载路径被缓存，就给它显式写一条静态规则；想要接口数据永远新，就什么都不配——把旁路当默认安全态。踩坑实录：纯 API 域名的模板若误设为缓存型，客户端会永远拉到旧票据与旧列表——模板选不缓存才对。
刷新链路：为什么 Purge 不是秒生效
缓存刷新的完整链路是：控制台签发任务入库 → 边缘节点周期性领取 → 节点删除对应缓存。领取与删除之间存在正常的分钟级延迟——如果业务不能接受这个窗口，正确方案依然是版本号：URL 一变，新旧即时原子切换，永不依赖刷新。
参数污染的另一面
攻击者与白嫖流量同样精通"参数进缓存键"的规则：拼出海量的随机参数 URL 逼节点次次回源，源站带宽瞬间被抽干。对策是忽略指定参数——缓存键只按路径归一，随机参数全部命中同一份。悠梦庭高防CDN 的防盗链与参数归一闸门防的正是这一手。
三句话自检
- 我改没改引用 URL？改了就不用管刷新；
- 这条路径命中缓存规则没有？看 X-Cache 与规则清单；
- 是不是在等节点领刷新任务？等一下，或改用版本号。