HTML5HistoryAPI实现无刷新单页面应用路由系统

构建无刷新的单页面应用，HTML5 History API是绕不开的核心技术。它让应用在切换视图时，地址栏的URL能够同步更新，并且支持浏览器的前进后退操作，用户体验和SEO表现相比传统哈希路由（#）均有明显提升。

这套机制看似复杂，拆解来看，核心环节只有三个：拦截用户的导航点击、更新浏览器地址栏、响应历史记录的变化。不依赖任何框架，原生JavaScript即可实现，关键在于将pushState、popstate与URL解析这几个API串联成一个完整的闭环。

拦截点击并更新URL

用户点击链接时，目标是不让页面刷新。这需要拦截默认行为，用JavaScript来接管导航流程。

• 监听导航事件：为所有需要路由控制的链接（例如带有data-router属性的标签）添加点击事件监听器。
• 阻止默认跳转：在事件处理函数中，第一时间调用e.preventDefault()，阻止浏览器执行页面跳转。
• 更新历史记录：从链接的href属性提取目标路径（如/about），执行history.pushState({ path: '/about' }, '', '/about')。此操作会修改地址栏URL，同时将自定义状态数据（此处传入path）压入历史堆栈。
• 更新页面内容：根据新路径加载对应内容，无论是渲染模板、请求接口数据还是替换DOM节点，均在这一步完成。

这样一来，用户感觉页面“跳转”了，地址栏也变了，但整个页面并未重新加载。

监听浏览器前进与后退

用户点击浏览器的前进或后退按钮时，URL会变化，但页面不会自动更新。这是因为pushState和replaceState触发的URL变化不会触发popstate事件，只有用户点击前进后退按钮，或调用history.back()、history.go()时才会触发。

因此，必须手动接管这一行为：

• 注册全局监听：通过window.addEventListener('popstate', handler)注册事件监听。
• 获取目标路径：在事件处理函数中，尝试从event.state对象读取之前存入的路径（如event.state.path）。如果state为空（例如用户直接输入URL访问或刷新页面），则需要回退到读取location.pathname。
• 同步视图：根据获取到的路径，重新执行内容加载逻辑，确保页面视图与当前URL保持同步。

处理初始加载与URL匹配

页面首次打开或用户刷新页面时，history.state的值为null，popstate事件也不会触发。因此，不能仅依赖事件监听，还需要主动进行初始化。

• 主动初始化路由：在应用启动的脚本中，立即读取一次location.pathname，并调用渲染逻辑，匹配并展示初始页面。
• 封装路径匹配函数：建议封装一个router.match(path)函数，其职责是将路径字符串映射到具体的组件、模板或数据加载逻辑。这是路由系统的“核心处理器”。
• 支持参数解析：让匹配函数支持简单的动态路由参数解析。例如，路径/user/123可以解析出{ id: 123 }这样的参数对象，用于后续的数据请求。

服务端配合不可或缺

这是History模式与Hash模式的最大区别，也是最容易出问题的环节。History模式使用真实路径（如/dashboard），而非带#的哈希路径（如#dashboard）。

这意味着，当用户直接在浏览器地址栏输入https://yoursite.com/dashboard并回车，或分享此链接时，请求会直接发送到服务器。如果服务器未针对真实路径/dashboard配置对应资源（实际上它只是一个前端路由），就会返回404错误。

因此，必须在服务器端进行配置，将所有非静态资源的请求重定向到应用唯一的入口文件（通常是index.html）：

• Nginx：在配置文件中添加try_files $uri $uri/ /index.html;。
• Apache：启用mod_rewrite模块，配置相应的RewriteRule规则，将请求回退到index.html。
• Vercel/Netlify等静态托管平台：在_redirects文件或vercel.json等平台配置文件中，设置规则将404错误重定向到/index.html或根路径/。

将这四个环节串联起来——拦截点击、响应历史、初始化匹配、服务端兜底——就能得到一个轻量、完全可控且对搜索引擎友好的前端路由基础。思路清晰后，实现起来并不复杂。