在 Web 开发中，缓存是一把双刃剑。对于静态资源，它能极大提升加载速度；但对于业务逻辑频繁变动的 H5 页面（如支付、订单页），缓存往往会导致用户看到过期的数据或界面。最近在维护一个 uni-app 项目时，遇到了一段关于 H5 缓存控制的逻辑，引发了我对于'后端重定向加时间戳'和'前端 JS 加时间戳'这两种方案的思考。虽然两者的最终目的一致，但在 Hash 模式下，它们的实现原理和效果有着本质的区别。
一、问题背景
在应用启动的生命周期中，通常会有这样一段逻辑：当用户访问特定的关键页面（如支付、订单页）时，如果当前 URL 中缺少时间戳参数，前端会自动解析 URL，追加当前时间戳，并强制页面刷新。
这就引出了一个问题：为什么不直接在后端重定向时加时间戳？这两种方式有什么区别？
二、核心区别：执行时机与作用域
虽然两种方式都能通过修改 URL 参数来欺骗浏览器，使其认为这是一个新请求，进而绕过缓存，但它们的工作流程完全不同。
我们可以用一个通俗的'进商场'例子来类比：
| 维度 | 后端重定向加时间戳 (迎宾员模式) | 前端 JS 加时间戳 (服务员模式) |
|---|---|---|
| 执行者 | 服务器 | 浏览器 |
| 发生时机 | 用户发起请求的瞬间，页面还未加载 | 页面已经加载，JS 开始运行后 |
| 工作流程 | 浏览器请求 -> 服务器拦截并返回 302 -> 浏览器自动跳转新 URL | 浏览器加载旧页面 -> JS 检测 URL -> JS 修改 href -> 浏览器跳转 |
| 用户体验 | 无感知，直接进入最终页面 | 可能会看到旧页面闪一下，然后跳转刷新 |
| 主要作用 | 解决入口缓存问题 | 解决内部路由缓存问题 |
三、为什么这里必须用前端方案？（Hash 模式的特殊性）
这段代码所在的 uni-app 项目是一个典型的 SPA（单页应用），且采用了 Hash 模式（URL 中包含 #）。这是选择前端方案的决定性因素。
1. 后端的'盲区'
在 Hash 模式下，URL 形如 http://example.com/#/order。
当用户在应用内部跳转（如从首页跳转到订单页）时，仅仅是 # 后面的 Hash 值发生了变化。这个过程不会向服务器发送 HTTP 请求，后端完全感知不到用户进入了哪个页面。因此，后端无法在用户进入特定页面时进行拦截并重定向。
2. 关键细节：时间戳加在哪里？
在 Hash 模式下实现前端刷新，有一个极易被忽视的细节：时间戳参数必须加在 # 号之前。
- ❌ 错误做法：加在
#后面（如#/order?t=123）。 这仅改变了前端路由状态，不会触发浏览器刷新，也就无法更新 HTML 或 JS 的缓存。 - ✅ 正确做法：加在
#前面（如/?t=123#/order）。 这改变了请求的 Base URL，迫使浏览器向服务器发起一次全新的请求，从而拉取最新的页面资源。
3. 兜底机制
当用户已经在应用内部跳转到了订单页，此时如果浏览器缓存了旧的 HTML 结构，用户可能看到错误的数据。这时候，只有运行在浏览器里的前端 JS能够感知到'我现在在订单页'并且'URL 里没有时间戳'，从而执行强制刷新逻辑。
