1. 认识 Window History：浏览器“记忆”的那本流水账

先问一个问题：你在浏览器的地址栏旁边，是不是几乎每天都要用到那两个箭头？左边是后退，右边是前进。点一下，页面切换了，可是页面并没有整体刷新，有时候甚至连请求都没发，地址栏的URL却变了。这背后靠的就是 JavaScript 里的window.history——一个专门管浏览器历史记录的全局对象。

很多人学前端的第一年，可能把location、window.open用得滚瓜烂熟，但对history往往只有一个模糊印象：知道它能后退、能前进，好像还有个pushState和什么popstate，但具体在什么场景下用、为什么用了之后页面却不刷新、为什么有时候在本地双击 HTML 文件用不了——完全没概念。今天我就把这块掰开揉碎讲清楚。

这个主题适合谁？三类人：

• 写前端页面但还没碰过路由的人，你需要知道history和location.href的本质差别。
• 天天用框架路由却不理解原理的人，比如用过 Vue Router、React Router，但不知道这俩东西底层到底是怎么监听地址变化、怎么渲染组件的。
• 写过 SPA（单页应用）但被“刷新后 404”“返回时状态丢失”坑过的人，这篇文章会给你一套完整的排查思路。

一句话概括：history是浏览器提供的“历史记录操作面板”，而我们前端工程师最常用的场景就是用pushState/replaceState在不刷新页面的情况下改变地址栏 URL，再配合popstate事件感知用户按了前进/返回，从而实现纯前端路由。

在往下写之前，我想先打个比方。浏览器里每开一个标签页，其实都有一本独立的“流水账本”，记录着你在当前标签页里访问过的每一个页面：打开某首页、点进某列表页、点进某详情页、跳到某个锚点……这就是历史记录。而window.history就是你控制这本流水账的工具。在这本账本里，浏览器不光记了网址，还记了标题、一份可选的“状态数据”，以及当前你在账本里翻到了第几页。这本书的翻页行为，最核心的数据结构是一个历史栈（History Stack）——先进后出，你每新打开一个页面，就像往栈顶压入一块积木，而“当前页”永远指向栈顶。

2. 核心 API 拆解：从最简单的“后退一页”到“改写历史”

2.1 三个基础操作：back、forward、go

当你拿到window.history这个对象，最直观的三个方法就是前进、后退、跳转。

• history.back()：相当于点击浏览器工具栏的“后退”按钮，回到上一页。
• history.forward()：相当于点击“前进”按钮，去往下一次曾访问过的页面。前提是你确实后退过，栈里还有“未来”的记录。
• history.go(n)：相对当前页跳转。go(-1)等价于back()，go(1)等价于forward()，go(-2)是后退两页，go(0)是重新加载当前页。

这三个方法都有一个共同特点：它们是异步感知、同源受控的。什么意思呢？就是如果历史栈里已经没有可退的页面了，你调用back()也不会报错，它就是安静地什么都不做。而在跨域的情况下，你如果在前一个域名的页面上调用了go(-2)，浏览器可能会因为你试图跨域操作而拒绝，甚至在某些实现里会有安全限制。

我实际工作中最常用到的是go(0)。这个在某些弹窗组件里特别有用：比如某些旧系统的页面状态脏了，又不想走location.reload()那么重（reload 会重新提交表单提示、闪烁白屏），就用history.go(0)做刷新。严格说它跟location.reload()差不多，但有细微差别，后面在常见问题里我会补充。

2.2 pushState 与 replaceState：不刷新页面改地址

这是整个history对象里最值钱的两个方法，也是 SPA 路由的基础。

history.pushState(state, unused, url)的作用是：往历史栈里新压入一条记录，并让地址栏的 URL 同步变成你传入的url。但注意：它不会触发浏览器去请求这个 URL，也不会重新加载页面。页面当前展示的内容完全不受影响，需要你手动通过 JS 去更新视图。

参数说明：

• state：一个任意的、可以被结构化克隆（Structured Clone Algorithm）序列化的 JavaScript 对象，比如{ pageId: 123, source: 'list' }。这个对象会和新记录绑定在一起，后续通过popstate事件的event.state或history.state取回。
• unused：这个参数名其实就告诉你它“没用”。历史上它曾被设计为表示页面标题，但后来各大浏览器都忽略它了，所以你传一个空字符串''即可，也有人习惯传null。
• url（可选）：新的历史记录的 URL。必须是同源 URL，否则会抛出SecurityError。如果省略，就默认用当前地址。

history.replaceState(state, unused, url)和pushState几乎一模一样，唯一的区别是：它不会新增历史记录，而是把当前这条记录直接替换掉。场景很好理解：SPA 里的 Tab 切换，你不想让用户每切一个 Tab 都产生一堆历史记录，按返回时还要一步步退回来。

举一个我做过模拟项目 X 的真实例子：某后台管理系统的列表页有筛选条件，用户在筛选页点了一次“搜索”，我把搜索参数pushState进了 URL。这样用户刷新页面后，URL 里带着参数，我也能通过读取 URL 参数恢复筛选状态。但如果用户只是在一个 Tab 列表里来回切换，我就只用replaceState，目的就是不让历史栈堆满无意义的重复页面。

2.3 状态读取与 popstate 事件

history.state这个属性，返回的就是当前地址对应那条历史记录绑定出来的 state 对象。如果当前条目是通过pushState或replaceState创建的，就返回对应的 state；否则返回null。

然后是popstate事件，这个事件的触发时机很关键：当用户在浏览器里点击前进/后退（或者代码调用back()、forward()、go()）时触发；但调用pushState和replaceState本身不会触发生popstate，甚至history.go()也不会。

这是个常被新手踩晕的点：我明明pushState了，为什么监听popstate没反应？因为它本来就不该触发。真正打开页面的时机，是你后来按下浏览器返回键的那一刻，popstate才姗姗来迟，还带着那个条目的state。

我建议把popstate理解为：浏览器这本流水账翻页之后，通知你说：“喂，现在页码变了，你有啥要善后的没？”而pushState自己是写账的人，写完当然不用通知自己。

3. 为什么说 History 是前端路由的地基

3.1 从零搭一个迷你前端路由

很多同学用过 Vue Router、React Router，知道它们分hash 模式和history 模式，也知道 history 模式更“干净”但需要服务端配回退。但底层到底发生了什么，我建议你亲手写一个极简路由来体会。

先看 hash 模式的核心思想：监听window的hashchange事件，地址栏#后面的部分变化时，解析location.hash的内容去匹配组件。

方案一：hash 模式 - 修改 hash：location.hash = '#/user/123' - 监听变化：window.addEventListener('hashchange', () => { render(location.hash) })

这虽然没有直接用history的 API，但也依赖了浏览器历史记录机制，因为每次hash变化都会在历史栈上留下一条记录，所以浏览器的后退依然能工作。

再看 history 模式的极简实现：

// 1. 点击导航时，不再用 <a href> 跳转，改成 JS 控制 function navigateTo(url) { history.pushState(null, '', url); renderRoute(url); // 手动更新视图 } // 2. 用户点击浏览器前进/返回时，通过 popstate 感知 window.addEventListener('popstate', () => { renderRoute(location.pathname); }); function renderRoute(path) { if (path === '/list') { // 渲染列表页组件 } else if (path === '/detail') { // 渲染详情页组件 } }

发现没有：hashchange和popstate就是两条核心命脉。而pushState相比同修改location.href的最大优势是：页面不刷新、不丢状态、不发请求。用户在同一个文档里切换视图，这对性能和体验的提升是质的飞跃。

不过别高兴太早，这种“纯前端路由”有一个绕不开的硬伤：当你把地址栏确定在/detail然后按 F5 刷新时，浏览器会带着这个 URL 向服务器发起请求，服务器如果没对这个路径做处理，就是 404。这一点我在第 5 节排查清单里会展开聊。

3.2 状态保存与恢复：返回列表页不“失忆”

我踩过最深的一个坑是这样的：列表页有几十条数据，用户滚动到第 20 条，点进详情，看完后按返回。按我预期，列表应该还在原来的位置，筛选条件也还在。结果页面重新加载了，列表回到了第一页，滚动条到了顶部，用户直接开骂。

后来我把这套逻辑梳理明白，分三个层面解决：

• 第一层：数据状态。列表页的筛选条件、当前页码这些，我用pushState把对象塞进了 URL，比如?page=2&keyword=abc。这样刷新、返回后，我读 URL 参数恢复状态。
• 第二层：组件内部状态。比如某个折叠面板是否展开、某个输入框的草稿内容，这些不适合全都塞 URL 的参数。我用sessionStorage按路由路径为 key 存了一份副本，在pageshow事件里恢复。
• 第三层：滚动位置。history.scrollRestoration这个属性派上了用场。它是'auto'或'manual'二选一。默认auto的时候，浏览器会自动恢复某些页面的滚动位置，但复合场景（比如弹窗、嵌套滚动容器）经常失效。我习惯在进入列表页面时设成history.scrollRestoration = 'manual'，自己在popstate里读取event.state里存的scrollTop来手动定位。

这样做完，用户体验才真正回升。这不仅仅是“技术方案”，而是在告诉浏览器：历史记录不只是一个 URL，它还是一颗“状态胶囊”，你回去的时候应该把页面恢复成当时的样子。

3.3 用 replaceState 做“不允许回退”的页面

再分享一个常见的应用场景：登录跳转、支付页、两次提交的表单。

有一次我做一个信息提交页，页面 A 是表单，提交成功后跳到成功页 B。我最初直接用pushState跳到了 B，结果用户按返回，又回到了 A，还看到自己填写的表单还没清空（因为页没刷新），再次点击提交，后端提示“重复提交”。这就是典型的历史栈污染问题。

正确姿势是在提交成功的时候用replaceState：

// 提交成功后，不新增历史记录，替换当前表单页记录为成功页地址 history.replaceState({ submitted: true }, '', '/success');

这样用户按返回，就不会回到“还能再提交一次的表单页”，而是回到他进入表单之前的那一页。这种细节在后台表单里极其重要，我后来在好几个项目里都用上了，屡试不爽。

4. 常见问题与排查技巧实录

这部分是我长期跟history打交道攒下来的一张“踩坑地图”，建议收藏着看。

还有一些不是错误、但非常影响体验的细节：

• history.state和event.state别搞混。history.state是当前条目的状态，popstate事件里的event.state是“切换过去的那条记录”的状态。听起来一样，但在多级路由里，如果你在返回切页时没更新自己保存的“当前状态”变量，就很容易错位。
• 监听器务必清理。SPA 里组件频繁挂载卸载，我在某项目里曾因为popstate监听器没有移除，导致切换了几十个页面后触发一次返回，所有页面的回调全部跑一遍，页面卡到肉眼可见地掉帧。后来我写的路由封装里，永远返回一个销毁函数。
• state对象必须可序列化。不能塞 DOM 元素、函数、循环引用，否则存进去是坏的。如果数据量大，别全堆在 state 里，存个 key，把数据放到sessionStorage里更稳。
• pageshow和persisted属性。如果你用了back-forward cache（BFCache，一种浏览器页面缓存机制），按返回时页面可能被恢复，而不是重新加载。这时如果监听的是load事件，永远不会触发。这时候要监听pageshow，并判断event.persisted为true时的状态恢复逻辑。

5. 框架层是怎么包装这套东西的：从 History API 到路由库

很多用框架的都好奇，Vue Router、React Router 这类库到底做了什么？“不就是监听popstate和pushState吗？”这话对，但粗暴。真实世界里它们封装了更多边缘情况。

以我自己的理解来看，一个成熟的路由库最少做了四件事：

1. 统一 location 抽象。把window.location的散落字段（hash、pathname、search、query参数解析）整合成一个结构化的location对象，方便组件读取，也方便做嵌套路由的匹配。
2. 统一的监听机制。内部维护一个订阅者列表，navigate的时候主动通知订阅者，而不是依赖开发者手动同步渲染。
3. 多端适配。浏览器环境用 history 实现，老浏览器用 hash 实现，还有内存路由（用于测试、SSR 等，不具备真实 URL）。这些，本质上都是把你看到的navigate这样的 API 翻译成底层实现。
4. 阻塞与守卫。比如你在切换路由时弹“确认离开？”的beforeunload提示，路由库需要协调这一套钩子，这在原生 API 上几乎要徒手写不少代码。

我也曾尝试自己在一个小项目里做一个极简的“框架”，当时的做法是维护一个listeners数组，暴露navigate(url)和listen(callback)。navigate里调history.pushState，然后手动遍历listeners通知每个订阅者；listen里挂载一个popstate监听器。这样一个小封装，只有几十行代码，但已经能支撑起一个中小型工具站的页面切换了。

这样做的收益是巨大的：你一但理解了这套底层，再去读任何路由库的源码，都会觉得它们是“意料之中”。看到createBrowserHistory、createHashHistory、createMemoryHistory这些名词，就不再困惑，而是知道它们分别对应 browser/hash/memory 三种历史记录实现。

6. 我的实操心得与几个小技巧

最后分享一些零零散散但真实有效的心得：

调试技巧：在浏览器 DevTools 的 Console 面板里，你可以直接输入history.length查看当前标签页的历史条数，输入history.state查看状态对象，输入history.go(-2)强制回退。这比手动点浏览器按钮快得多，尤其是在测试深层跳转的时候。

监听事件的另一种写法：除了addEventListener('popstate', ...)，早年还有window.onpopstate = ...的写法。两者基本等价，但addEventListener可以挂多个回调，更灵活。写框架封装时，统一用addEventListener，并在销毁时removeEventListener，已成我的铁律。

尽量不要手动修改history里的 URL 成奇形怪状的形式。我见过有人把整个业务对象编码在 URL 里，比如/detail/MzE5OTgxMjE=。这既丑又容易撑爆地址栏。合理做法是 URL 里只放维度最少的主键、页码、筛选关键字，复杂数据走state或sessionStorage。

history.length其实是只读的。有人天真地想过 “我把 length 改小一点，是不是就能清理历史记录？”答案是不能。出于安全原因，历史记录只允许追加和替换当前条目，不允许随意删除指定条目。所以你想让用户“无法返回某页”时，只能用replaceState替换掉不需要的页，或者用location.replace()提前处理。

最后一个贴心提示：在移动端 WebView 里，Android 的物理返回键会触发popstate，但 iOS 却不一定。这时候监听的可靠性就打了折扣。如果你要做一个“按返回键关闭弹窗”的功能，建议同时监听popstate和visibilitychange事件内部兼容处理。iOS 的返回手势和浏览器返回事件的耦合相当微妙，真正需要做“返回拦截”的场景，得考虑成熟的“状态锁”模式，也就是预存标记 + 对比。

老实说，JavaScript Window History 这套 API 很老、很长寿，很多初学者觉得它“不起眼”。但这些年我经历过的每个前端项目，几乎都逃不开它：SPA 路由、页面状态恢复、返回拦截、滚动定位、表单防重复提交……越是基础的东西，越值得花时间把它吃透。希望这篇文章能帮你少走几步弯路。