看似正常，但问题往往在“第二次打开”、或换个页面再回来时，行为变了——原来的参数不见了，反而被其他参数或跳转绑住了。背后有几条关键线索需要弄清楚：浏览器缓存（包括HTTP缓存、localStorage、IndexedDB、serviceworker缓存）会记录页面或脚本的某些状态；跳转参数会被脚本读取并写入本地存储，从而影响之后的跳转逻辑。
活动主办方与推广方常用的套路是：通过URL参数标识来源与分成，然后在页面脚本里把这些参数存入localStorage或cookie，以便后续打开页面或子站点时能“识别”来源并返佣。这本身是业务需求，但当参数写入的逻辑与缓存过期、重定向策略、服务工作线程（serviceworker）缓存规则混在一起时，就会产生“劫持感”。
举个更具体的例子：A链接带上ref=affiliateX，页面脚本把它存到localStorage并注册了一个serviceworker，SW会拦截导航请求并根据localStorage里的值对请求发起新的重定向，结果用户每次访问相关域名都会被送到含有affiliateX的落地页——这看起来像是“浏览器被劫持了”，但技术上是脚本与缓存策略在后台操作。
还有一种更隐蔽的情形是预取(prefetch)或缓存静态资源时把带参URL存为索引，后来从缓存拿到的页面带着旧参数继续影响跳转。简单来说，缓存保存了状态，跳转参数提供了规则，两者一结合，就能把一次性推广变成持续性的重定向体验。理解这点，比单纯把问题归咎于“被劫持”更有助于判断下一步该怎么做。
按这个时间线，有几项快速检查能帮你判定问题来源：检查地址栏参数变化，打开开发者工具的Application/Storage面板，看localStorage、IndexedDB、cookie里是否保存了推广参数或跳转标志；在ServiceWorker面板查看是否有注册并拦截请求；使用无痕/隐私窗口或清除sitedata后再试，判断问题是否随本地存储消失；用curl或换设备访问同一URL，确认后端是否返回重定向响应。
决定是否采取更激烈的措施时，参考这三条逻辑：是单一域名的行为（倾向于页面脚本或local缓存问题），还是跨域普遍存在（可能是第三方脚本或ISP层面的劫持）；是否涉及金钱返佣或流量分成（意味着对方有动力长期保持这种行为）；清理本地存储或禁用serviceworker能否临时解决问题。
给出几种低成本的应对策略：短期内可清理站点数据、用隐私窗口、禁用第三方cookie或脚本；如果你是站长，则检查是否将推广参数写入持久存储，审计serviceworker逻辑与缓存策略；如果怀疑是更深层的劫持（如流量劫持或DNS劫持），换网络、联系运营商或安全专家进行溯源。
看完这些脉络后，你可以更冷静地决定下一步：只是清理缓存、调整浏览习惯，还是要追溯并修补代码，甚至发起投诉或法律行动。
