前端路由原理与JS实现解析

前端路由的本质是在不刷新页面的前提下，通过 history.pushState 或 hashchange 拦截 URL 变化、动态切换视图，从而维持单页应用（SPA）的流畅体验与状态连续性；它绝非服务器转发，而是一场精妙的状态协同——既要规避 window.location.href 导致的 JS 状态丢失和白屏重建，又要应对同源限制、服务端配置、首次加载触发、SEO 折衷等现实约束，更深层的挑战在于 URL、历史栈、组件树、滚动位置与表单数据的实时一致，稍有不慎，嵌套路由、参数解析或路由守卫就会让“手写路由”迅速失控。

前端路由不是服务器转发，而是浏览器在不刷新页面的前提下，靠 history.pushState 或 hashchange 拦截 URL 变化、动态切换视图的机制。

为什么不能直接用 window.location.href = '/user'？

这样会触发完整页面跳转，丢失当前 JS 状态（比如表单输入、滚动位置、Vuex/Pinia 数据），违背单页应用（SPA）的设计目标。

常见错误现象：

• 页面白屏一闪，React/Vue 组件被完全销毁重建
• 控制台报错 Uncaught DOMException: Failed to execute 'pushState' on 'History'（跨域或协议不匹配时）
• 后退按钮失效，或回退到上一个真实页面而非上一个路由

history.pushState + popstate 是最接近原生的实现方式

它操作浏览器历史栈，URL 改变但不发请求，适合现代 SPA。注意：需要服务端配合——所有路由路径都返回同一份 HTML（否则刷新 404）。

实操要点：

• 初始化时用 history.replaceState 抹掉初始状态，避免多按一次后退跳到空白页
• 监听 popstate 事件处理浏览器前进/后退，但该事件不触发于 pushState 调用，需手动 dispatch
• pushState 的第三个参数是 URL，必须是同源的相对路径（如 '/user/123'），不能是完整 URL（如 'https://a.com/user'）
• 路由匹配建议用 new URL(event.state?.url || location.href).pathname 提取路径，兼容 state 为空的情况

function goTo(path) {
  history.pushState({ url: path }, '', path);
  router.dispatch(path); // 手动触发渲染
}
window.addEventListener('popstate', e => {
  const path = new URL(e.state?.url || location.href).pathname;
  router.dispatch(path);
});

hashchange 兼容性更好但 URL 不够美观

适用于需要支持 IE9 的老项目，URL 形如 #/user，改变 hash 不触发页面请求，也无需服务端配置。

关键差异：

• 监听 hashchange 事件，location.hash 返回带 # 的字符串，需用 slice(1) 截取
• 首次进入页面时 hashchange 不触发，要手动执行一次路由匹配
• SEO 不友好，搜索引擎通常忽略 hash 后内容
• 无法使用 history.length 或 history.scrollRestoration

window.addEventListener('hashchange', () => {
  const path = location.hash.slice(1) || '/';
  router.dispatch(path);
});
// 首次加载
router.dispatch(location.hash.slice(1) || '/');

真正难的不是写几行 pushState，而是状态同步：如何让 URL、浏览器历史、组件树、滚动位置、表单数据始终一致。很多“手写路由”在嵌套路由、参数解析、路由守卫、异步加载这些环节开始失控。

本篇关于《前端路由原理与JS实现解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！