先说说啥叫页面刷新

哎，先把概念抖开。

页面刷新其实就是浏览器把当前文档全部丢掉。

重新去服务器要 HTML、CSS、JS。

那叫“全盘托出”。

你点 F5，或者 location.reload，dou是这玩意儿。

说实话，这时候 JavaScript 环境全dou重新搭建。

所有变量dou没了事件监听也得重新挂。

所以刷新会导致 UI 瞬间白屏，资源再拉一次。

再聊聊路由跳转

这玩意儿跟刷新的感觉完全不一样。

单页应用里我们用 JS 把 URL 换了却不让浏览器走老路。

Vue Router、React Router dou是这么干的。

它们监听 popstate 或 hashchange，然后动态换组件。

页面根结构不动，只有局部 DOM 被替换。

所以你kan到 URL 变了内容也变了但地址栏左边的旋转图标根本不转。

两者到底怎么区分？

先说Zui直观的——网络请求。

刷新必然会发一次 GET 请求拿完整的 HTML 文档。

而路由跳转，只要是 SPA，就只会走一次 API 请求或根本不请求新资源。

再kan JavaScript 生命周期。

刷新时 window.onload 会重新触发，一切初始化代码dou会跑一遍。

路由跳转则不会走 onload，只会走框架自己的钩子，比如 beforeRouteEnter、useEffect 等等。

用原生 API 判断

performance.navigation.type 在旧浏览器还Neng给你个数字：

type===1 表示 reload，type===0 表示普通导航，type===2 表示后退/前进。

不过现代浏览器Yi经把它废弃了你Ke以kankan performance.getEntriesByType.type ，值可Neng是 'reload' 或 'navigate' 或 'back_forward'。哈哈，这玩意儿挺靠谱的。

监听 beforeunload 与 popstate

Ru果你在页面里加个 window.addEventListener，那它只会在真正离开页面或刷新的时候触发。咱就是说路由跳转一般不会走这个事件，因为页面根本没卸载。你懂的，这点Ke以用来区分两者。

相反，window.addEventListener 则专门捕获历史记录的变化——后退、前进以及通过 history.pushState/replaceState 的“伪导航”。 AOP 那点小技巧：自定义标记

有时候我们想自己明确区分，就在调用路由跳转前手动打个标记：

// 假设用 Vue Router
router.beforeEach => {
    window.__isRouterNavigation = true;
    next;
});
window.addEventListener => {
    if  {
        // 是路由跳转，不是真正的刷新
        delete window.__isRouterNavigation;
    } else {
        // 真正的刷新或关闭
    }
});

bingo，这招在调试埋点时特别好用。害，这段代码写着写着我自己dou差点忘了删掉注释……不对不对，我应该把注释改成 “这里标记一次路由导航”。

Spa 框架内部怎么Zuo到“不刷”

P.S. Vue 用的是 History API 的 pushState/replaceState，再配合 listen popstate 来实现 URL 同步而不触发加载。React Router 基本同理，只是内部用了一个叫 “Router” 的组件来管理状态。说实话，这背后其实也没多神秘，就是把浏览器默认行为阻止掉，然后自己接管渲染流程罢了。

常见坑 & 防坑指南

#1 刷新后状态丢失： hen多同学在 SPA 里把重要数据直接存在内存变量里一刷就全没了。解决办法：利用 localStorage / sessionStorage / IndexedDB 持久化，或者把关键状态写进 URL query 参数里。哈哈，有时候我就懒得弄，直接让用户手动保存一下……咱就是说这算不上Zui佳实践吧？你懂的。

#2 路由守卫误判： 有的小伙伴在 beforeRouteLeave 里直接调用 location.reload 想强制刷新，却忘记这会导致整个应用重新挂载，性Neng骤降。正确Zuo法：Ru果真要硬刷，就先清理一下全局状态，再 reload，否则Ke以考虑只geng新局部数据即可。说实话，我曾经这么干过一度卡到控制台满屏红字……不对不对，那是我忘记加 try...catch 导致异常未捕获啦！

#3 浏览器兼容性： 老 IE 不支持 History API，只Neng靠 hash 模式实现伪路由。这种情况下你得判断下是否支持 pushState，不行就回退到 #/xxx 的形式。别忘了在 hash 模式下 refresh 会导致服务器返回错误，因为服务器根本不知道 # 后面的东西。哈哈，这坑真的hen深，我当年踩过好几次呢！

A/B 测试：怎么监控用户到底是刷了页还是走了路由？

A/B 测试经常需要区分两类用户行为，以便评估新功Neng影响效果。

- 在每次 page load 时埋点发送 “full_load”。

- 在每次 router.afterEach 时发送 “spa_navigate”。

- Ru果检测到 beforeunload 且没有标记为 spa_navigate，则算作 “hard_refresh”。

Bingo！这样你就Neng清晰划分出三类访问路径啦。哈哈，kan起来有点技术感，其实就是把事件分类收集罢了。咱就是说用好这些细粒度事件，你的数据报告会geng精准，也geng容易找出性Neng瓶颈所在。你懂的~

Dive deeper：Performance Timing API 实战演示

// 获取Zui近一次导航信息
const nav = performance.getEntriesByType;
if  {
    console.log; // 'navigate' | 'reload' | 'back_forward'
    console.log;
}

——别被表象骗了！

# 刷新 = 全部重装，所有脚本重新执行；# 路由 = 局部换装，仅geng新视图层面；# 检测 = kan网络请求、生命周期钩子和 Performance API；# 实战 = 用 beforeunload + popstate + 自定义 flag 搞定；# 注意 = 持久化状态、防止误判、兼容老浏览器。这几个点记住你基本上就Neng在任何项目里准确区分“刷”和“跳”。哈哈，是不是有点像侦探破案的感觉？说实话，我自己每次写完监控代码dou有一种成就感——像找到隐藏彩蛋一样爽！咱就是说下次遇到疑惑，只要打开 console kan一眼 nav.type 或者追踪 beforeunload 标记，就Neng立马搞定啦。懂得dou懂，祝大家编码顺利，别被意外刷新给整晕！😊

)

---