上个月有个做家居内容站的客户跑来找我，问了个挺具体的事儿：站点加了PWA支持，Service Worker上线之后，跳转插件在部分回访用户身上就像是"没生效"——同一个入口链接，新用户点进去跳得好好的，老用户点进去直接落在缓存页面里了，跳转逻辑压根没跑。这到底是插件坏了，还是缓存把跳转吃掉了？多半是后者。Service Worker的fetch拦截一旦命中缓存，页面可能根本不发起网络请求，插件脚本的加载与判定时机就被整体前移或者干脆跳过了。要确认这件事，靠肉眼看现象不够，得有一套按阶段推进的验证工作流。
下面这份清单按准备、执行、复盘三段组织，每一段都写清楚输入是什么、验收标准是什么，适合有跳转插件配置经验的团队直接拿去改造成自己的检查表。
准备阶段：先把缓存策略和插件配置对齐成一份可验证的基线
准备阶段的目标不是测试，而是把"要验证什么"固定下来。PWA场景下跳转行为出问题，八成是缓存策略和插件加载时机没对齐，如果基线不清楚，执行阶段测出来的现象根本没法归因。
先打开站点的Service Worker文件，逐条确认三件事：哪些请求走cache-first，哪些走network-first，哪些直接放行不拦截。跳转插件自身的脚本文件、以及插件判定后要跳转的目标URL，必须明确落在哪一类里。常见的坑是插件脚本被写进了预缓存列表，版本更新后缓存没刷新，用户拿到的还是旧脚本，判定规则自然对不上。操作上建议把插件脚本单独标注为network-first或stale-while-revalidate，并在缓存键里带上版本号；验证方法是手动改一次插件配置，观察回访用户多久能拿到新逻辑。
跳转插件的触发通常依赖页面DOM就绪、或某个异步接口返回。PWA场景下要额外确认：插件是在Service Worker注册之前还是之后加载，判定逻辑是否依赖首次网络请求返回的数据。如果依赖，而该请求又被缓存接管，判定输入就可能是旧的。这一步的验收标准是能画出一张简单的时序图：页面请求→SW拦截→缓存命中或回源→HTML解析→插件脚本加载→判定→跳转。图上任何一环标不出来，执行阶段就会白测。
准备四类测试场景与对应账号
准备阶段还要把执行阶段的场景提前定好，至少覆盖：首次访问（无缓存）、二次访问（缓存命中）、离线状态、弱网（限速到能加载HTML但脚本可能超时）。每类场景准备独立的浏览器配置文件或设备，避免缓存状态互相污染。验收标准是每个场景都有明确的预期结果描述，比如"二次访问时插件仍应完成判定并跳转，耗时不超过首次访问的1.5倍"——这里的倍数是团队自己定的容忍线，不是外部标准。
执行阶段：按场景逐项跑，重点抓"缓存命中但跳转没跑"的分叉
执行阶段最容易犯的错是一次性把所有场景混着测，结果缓存状态乱了，现象对不上号。正确做法是一个场景一个场景过，每个场景都记录三样东西：网络请求面板里插件脚本和目标URL的请求状态、控制台有无SW相关报错、插件日志里判定是否执行。
首次访问与二次访问的对照
首次访问时清空所有缓存，确认插件正常加载、判定正常、跳转正常，这是基准。二次访问时不要清缓存，直接重进同一入口，重点看两件事：插件脚本是从SW缓存拿的还是回源的，判定逻辑有没有因为拿到旧脚本而行为变化。如果二次访问跳转没触发，先看请求面板里插件脚本的状态码是不是显示"from Service Worker"，这一步能快速区分是缓存问题还是插件本身问题。
离线与弱网条件下的降级行为
离线场景要验证的是插件在拿不到判定依赖时的降级策略：是静默失败留在当前页，还是阻塞页面渲染等待超时。两种都可以接受，但不能出现页面白屏或跳转目标错乱。弱网场景用浏览器限速功能模拟，重点观察插件脚本加载超时后是否有兜底逻辑。这里的验收标准建议写成"离线时页面可正常浏览，跳转行为按配置的降级策略执行，不出现不可恢复的卡死"，而不是要求离线也能跳转——那本身就不合理。
缓存版本更新后的行为回归
这一项经常被跳过。做法是：更新一次插件配置或SW缓存版本，然后让一个已经有旧缓存的浏览器重新访问，确认旧缓存被正确替换、新判定逻辑生效。如果发现旧缓存长期不失效，说明缓存键设计或SW的activate逻辑有问题，得回到准备阶段改配置。执行阶段这一项的验收标准是"配置变更后，回访用户在合理时间内拿到新行为"，合理时间由团队按业务节奏定，比如一个自然日。
复盘阶段：用日志比对和验收清单收口，别停在"看起来好了"
执行阶段跑完，现象可能都正常，但这不等于验证完成。复盘阶段要做的是把执行阶段收集的日志、请求记录和预期基线逐项比对，形成可以留档的结论。
日志比对的三条线
第一条线是插件判定日志：每个场景下判定是否执行、输入是什么、输出是什么。第二条线是网络请求日志：插件脚本和目标URL的实际请求来源（缓存还是回源）。第三条线是SW自身的日志或缓存命中记录。三条线对齐之后，才能说清楚"这次跳转为什么发生或为什么没发生"。如果三条线对不上，比如插件日志显示判定了但请求面板没有目标URL请求，那问题多半在跳转触发环节而不是缓存层。
验收清单的收口项
复盘阶段建议固定一张清单，至少包含：四类场景是否全部覆盖、每类场景的预期与实际是否一致、缓存版本更新后的回归是否通过、是否存在需要回退配置的项、遗留问题是否有明确的责任人和复查时间。这张清单的作用不是走形式，而是防止"测的时候好好的，上线一周后又冒出来"这类问题没人跟。
把结论写回配置文档
复盘的最后一步是把这次验证中确认的缓存策略、插件加载顺序、降级行为写回配置文档，作为下次变更的基线。很多团队反复踩同一个坑，就是因为验证结论只留在聊天记录里，人一换就断了。
一个家居流量团队的匿名复盘案例
某做家居内容聚合的团队，日均访问量在几万PV量级，服务器是一台中等配置的云主机加CDN，半年前给站点加了PWA支持，主要想提升回访体验。跳转插件是更早之前就配好的，按来源和页面类型做分流。PWA上线初期没觉得有问题，直到有运营反馈"老用户点进来好像不跳了"。
他们最初的排查方向是插件本身，反复检查规则配置，没发现问题。后来把Service Worker的缓存列表拉出来看，才发现插件脚本和目标页面的几个静态资源都被写进了预缓存，而且缓存键没有版本号。结果是：新用户第一次访问时脚本回源，行为正常；老用户二次访问时脚本从缓存拿，而缓存里那份是插件改规则之前的旧版本，判定逻辑自然对不上。更麻烦的是，因为目标URL也在预缓存里，部分跳转即使触发了，用户看到的还是缓存页面。
调整过程分三步：先把插件脚本改成network-first并加版本号缓存键；再把跳转目标URL从预缓存列表里移出去，改为运行时缓存且设置较短的过期时间；最后补了一套按场景跑的验证流程，就是上面说的准备、执行、复盘三段。调整后他们没有追求"所有场景都跳转"，而是明确了离线时按降级策略留在当前页、弱网时给一个可接受的超时上限。跑了两周回访数据，运营反馈的"不跳"现象基本消失，剩下的个别情况都能在日志里对上原因。这个案例里没有什么高深技术，关键就是把缓存范围和插件加载时机当成一件事来管，而不是分开看。
实施要点：几条容易漏掉的边界
- 跳转插件的脚本文件不要和业务静态资源共用一套缓存策略，前者对版本敏感，后者可以长缓存，混在一起必然出问题。
- 验证离线场景时，要区分"SW已注册且缓存完整"和"SW注册了但缓存没填满"两种状态，后者更容易出现判定依赖缺失。
- 缓存版本更新后的回归测试，建议固定用同一台设备或同一个浏览器配置文件，避免环境差异干扰结论。
- 复盘结论要写清楚"哪些行为是设计内的降级"，否则下次有人看到离线不跳转，又会当成bug重新查一遍。
回到开头那个问题：PWA离线缓存开启后跳转插件"没生效"，多数时候不是插件坏了，而是缓存层把插件的输入或输出截住了。按准备、执行、复盘三段走一遍，把缓存策略、加载时机、降级行为三件事对齐，再用日志比对收口，这类问题基本都能定位到具体环节。验证工作的价值不在于跑多少场景，而在于每个场景的预期和实际都能对上号、留得下记录。
