什么是页面跳转缓存分层
说到底，页面跳转缓存分层要解决的一个核心问题就是：跳转这条链路上，浏览器自己存了一份缓存，边缘节点也存了一份，两边各管各的。只要有一边没跟上失效节奏，用户实际走的跳转规则跟你配置里写的就对不上。这个判断基本上决定了整套东西该怎么设计——目标不是让某一层缓存的命中率飙到多高，而是让多层之间的失效节奏始终处于可控状态。
展开讲的话，用户发一次页面跳转请求，决策链路里一般牵扯到两个缓存层级。一层在浏览器本地，放的是跳转规则摘要、目标 URL 映射、还有那种短时有效的决策令牌之类的东西；另一层在 CDN 边缘节点上，存的是规则引擎算出来的结果，或者预渲染好的跳转响应。这两层的 TTL（Time To Live，存活时间）往往不是同一个人定的——浏览器缓存听 HTTP 响应头的，边缘节点缓存则受 CDN 配置和源站缓存策略双重影响。运营改了一条跳转规则，假如只刷了边缘节点、没管浏览器那边，那已经来过的用户在本地缓存过期之前，照样走的是旧规则。反过来说，浏览器缓存设太短、边缘节点设太长，那请求就哗哗往源站穿透，决策延迟直接上去了。
这块东西属于页面跳转技术体系里的缓存治理子域。它跟单纯的 HTTP 缓存优化不是一回事，关注点在多层缓存之间的一致性协调，而不是把某一层的命中率往死里拉。
分层结构：浏览器层与边缘节点层各管什么
浏览器层缓存的职责与约束
浏览器这边存的东西大致分三类。一类是跳转规则的版本标识，比如 ETag 或者 Last-Modified 值，拿来快速判断本地规则过没过期；一类是短时效的决策结果，像是“这个用户在当前会话里应该跳到目标 A”这种判定结论；还有一类是跳转目标的 URL 映射表，规则数量有限、变更又不频繁的场景下比较适用。浏览器缓存最大的好处是零网络开销，用户第二次来的时候压根不用问边缘节点，本地就把跳转决策做完了。但约束也很明显——可控性弱。运营方只能通过 Cache-Control、Expires 这些响应头间接影响缓存行为，没法强行清掉用户侧已经存下的东西，除非上 Service Worker 这类主动更新机制。
边缘节点层缓存的职责与约束
边缘节点缓存干的是“就近决策”的活儿。CDN 节点收到用户请求，先看本地有没有能用的跳转规则缓存或者决策结果缓存；有、而且没过期，直接把跳转响应返回去，根本不用回源。边缘节点的可控性比浏览器层强不少：运营方可以通过 CDN 管理后台主动刷新指定 URL 或者目录的缓存，也能用版本化 URL（比如规则文件路径带 hash 值）来做精确失效。麻烦在于节点数量多、分布又广，刷新操作存在传播延迟，不同节点刷完的时间可能差个几秒到几十秒。
正常跑起来的时候，浏览器层的缓存是依赖边缘节点返回的响应头和内容的。边缘节点返回跳转响应时，会捎带缓存策略指令，告诉浏览器该缓存多久、什么时候需要重新验证。这两层之间不存在谁主谁从，各自独立生效，靠失效信号来协同。设计上的关键点在这儿：边缘节点返回的缓存指令必须跟源站规则变更的节奏对齐，不然浏览器层会在完全不知情的情况下继续用过期规则。
协同失效机制：怎么让两层缓存同步更新
最常见的一招是在跳转规则里嵌版本号。规则文件路径或者决策接口的查询参数里带上当前版本标识，类似 v=20250115a 这种。规则一变，版本号往上走，浏览器和边缘节点都会把它当成新资源，绕过已有缓存重新取。好处是失效逻辑简单，不依赖缓存刷新接口；坏处是每次变更都导致全量缓存失效，命中率归零之后还得重新预热。
基于TTL梯度的被动失效
换个思路，让两层缓存的 TTL 形成梯度：浏览器层短一些，30 秒到 2 分钟这个区间；边缘节点层稍长，2 到 5 分钟。源站规则变更后，浏览器层先过期、回边缘节点验证，边缘节点再回源确认。这种方式对缓存命中率更友好，但有个窗口期绕不开——浏览器层已经过期、边缘节点还没回源确认的这段时间里，不同用户可能命中不同版本的规则。窗口期多长，取决于两层 TTL 的差值以及边缘节点的回源验证频率。
混合策略：主动信号加被动过期兜底
实际工程里更常见的是混合着来：时效性要求高的规则变更，比如紧急下线某个跳转目标，直接用版本号强制两层失效；常规的规则调整就靠 TTL 梯度自然过渡，同时用 CDN 的主动刷新接口把边缘节点的传播延迟压一压。混合策略里有个关键参数叫“最大不一致窗口”——从规则变更开始，到所有活跃用户都用上新规则，这段最长可接受时间是多少。这个窗口决定了 TTL 梯度具体取什么值，以及要不要引入主动失效。
适用条件与边界
缓存分层协同失效不是所有跳转场景都得上。它适用的条件大概是：跳转规则变更频率中等，日均几次到几十次；用户复访率比较高，缓存命中确实能带来收益；对跳转一致性的容忍窗口在秒级到分钟级。规则几乎不变的场景，单层长 TTL 缓存就够了；规则每秒都在变的话，缓存分层反而添乱，不如直接走实时决策。
边界这块有三条硬限制。浏览器层缓存没法被强制清除，只能等 TTL 自然过期，或者通过版本号引导重新请求——这意味着任何指望“立即全局生效”的规则变更，都不能只靠缓存分层来实现。边缘节点缓存的刷新传播延迟跟 CDN 节点数量和网络拓扑有关，跨区域部署时传播延迟可能达到数十秒，设计窗口期的时候得把这块算进去。还有一点，两层缓存的失效信号传递依赖客户端行为，用户要是关了浏览器或者清了缓存，协同失效的状态就重置了，下次访问时重新建立。
有个实际项目里遇到过这样的情况：某工具类产品的落地页跳转规则日均调整两三次，早期把浏览器缓存设了 10 分钟、边缘节点设了 30 分钟，结果运营改完规则后总有部分用户走旧的目标页，排查下来是浏览器层 TTL 过长导致的。调整方案是把浏览器层 TTL 压到 60 秒、边缘节点压到 3 分钟，同时给规则文件路径加了内容 hash 作为版本标识。调整后规则变更的生效窗口从原来的 10 分钟以上缩短到 2 分钟以内，边缘节点的回源请求量增加了约三成，但还在容量范围内。这个案例的关键教训就是：缓存分层的 TTL 设定不能拍脑袋，得从规则变更频率和可接受生效窗口反推。
相邻概念对比
HTTP 缓存策略管的是单个资源在单层缓存里的存取规则，核心是 Cache-Control、ETag、Last-Modified 这些头部字段怎么配。页面跳转缓存分层管的是多个缓存层级之间的状态一致性，它建立在 HTTP 缓存机制之上，但解决的问题不一样——前者回答“这个资源该不该缓存”，后者回答“多层缓存之间怎么同步”。
与CDN缓存刷新的区别
CDN 缓存刷新是边缘节点层的运维操作，指通过管理接口主动让指定 URL 的缓存失效。缓存分层协同失效是个更上层的设计框架，它决定何时需要刷新、刷新哪一层、刷新完浏览器层怎么跟进。CDN 刷新是协同失效策略里的一个执行动作，它本身不等于策略。
与跳转规则版本管理的区别
跳转规则版本管理关注的是规则内容本身的变更记录、回滚和审计，属于配置管理范畴。缓存分层协同失效关注的是规则变更之后，各缓存层怎么感知并响应变更，属于运行时一致性范畴。两者配合着用：版本管理提供变更标识，缓存分层消费这个标识来触发失效。
常见问题
一般不建议。两层 TTL 完全相同的话，理论上能同时过期，可实际上浏览器缓存的过期判断依赖本地时钟，边缘节点的过期判断依赖节点时钟，两者之间存在时间偏差。设成梯度，让浏览器层短于边缘节点层，可以让浏览器层先触发验证请求，由边缘节点统一裁决是否回源，不一致窗口就小了。梯度差值建议在 30 秒到 2 分钟之间，具体看规则变更频率和可接受生效窗口来定。
怎么验证协同失效是否生效？
可以在规则变更后，从不同网络位置和不同浏览器会话发起跳转请求，观察返回的目标 URL 是否一致。更系统的做法是在跳转响应里附带规则版本标识，通过日志采集统计各版本的实际命中比例，当旧版本命中比例降到预设阈值以下时，就认为本次失效完成了。这个验证方法不依赖什么特定工具，用基础的请求捕获和日志分析就能实现。
