深入理解 hash 和 history:网页导航的基础(上)

发布时间:2023年12月17日

在这里插入图片描述

🤍 前端开发工程师(主业)、技术博主(副业)、已过CET6
🍨 阿珊和她的猫_CSDN个人主页
🕠 牛客高级专题作者、在牛客打造高质量专栏《前端面试必备》
🍚 蓝桥云课签约作者、已在蓝桥云课上架的前后端实战课程《Vue.js 和 Egg.js 开发企业级健康管理项目》《带你从入门到实战全面掌握 uni-app》

一、引言

介绍 hash 和 history 的背景

Hash 和 History 是两种不同的路由模式,它们的背景如下:

  • Hash 模式:
    • URL 中的 hash 值只是客户端的一种状态,不会被发送到服务器。
    • hash 值的改变都会在浏览器的访问历史中增加一个记录,因此可以通过浏览器的前进、回退按钮控制 hash 的切换。
    • 可以通过 JavaScript 对 location.hash 进行赋值,来改变 URL 中的 hash 值。
    • 可以用 hashchange 事件监听 hash 值的变化,从而对页面进行跳转并渲染。

在这里插入图片描述

  • History 模式:
    • HTML5 提供了 History API,可以在不进行刷新的情况下,操作浏览器的历史纪录。
    • 可以使用 popstate 事件来监听 URL 的变化,从而对页面进行跳转和渲染。
    • history.pushState()或 history.replaceState()不会触发 popstate 事件,这时需要手动触发页面跳转。

在这里插入图片描述

总的来说,Hash 模式是早期的路由实现方式,而 History 模式则是 HTML5 提供的一种更现代的解决方案。

为什么需要了解 hash 和 history

在前端开发中,了解 hash 和 history 是很重要的,因为它们是实现前端路由的两种主要方式

具体原因如下:

  • 构建SPA(单页面应用):对于 Vue 这类渐进式前端开发框架,为了构建 SPA,需要引入前端路由系统,这也就是 Vue-Router 存在的意义。
  • 实现页面跳转:浏览器提供了两种支持前端路由的方式,即 hash 和 history。通过改变 URL,实现页面跳转,同时不会向后端发送请求。

总的来说,了解 hash 和 history 对于构建高效、用户友好的前端应用程序至关重要。

二、 hash 的基本概念

在前端路由中,hash指的是 URL 中的#符号后面的部分。例如,https://example.com/#/about中的#/about就是一个hash

  1. 什么是 hash: 在前端路由中,hash是指 URL 中#后面的部分。它可以用来在不刷新页面的情况下,通过改变hash值来进行页面的导航。

  2. hash 的特点和用途:

  • 不发送给服务器:浏览器在访问带有hash的 URL 时,不会将hash部分发送给服务器。这意味着服务器端无法获取或处理hash值。
  • 只在客户端生效:hash的变化只在客户端生效,不会导致服务器端的请求或页面刷新。
  • 简单且兼容性好:hash的实现相对简单,并且在大多数浏览器中都得到了很好的支持,包括旧版本的浏览器。
  • 用于前端路由:在单页面应用(SPA)中,前端路由可以利用hash来进行页面的切换。通过监听hashchange事件,可以根据hash的变化来加载不同的页面内容。

在这里插入图片描述

  1. hash 的变化和更新机制: 当用户点击链接或在浏览器中手动修改hash值时,浏览器会触发hashchange事件。在hashchange事件中,可以通过获取当前的hash值来进行相应的页面更新或路由处理。此外,还可以通过使用 History API(如 HTML5 的 History API)来实现更高级的前端路由功能,提供更好的用户体验。

三、 history 的基本概念

在前端路由中,history指的是 History API,它是 HTML5 提供的一种用于管理浏览器历史记录的接口。通过 History API,可以在不刷新页面的情况下,修改 URL 的hash值或使用新的 URL,实现页面的导航和状态管理。

  1. 特点:
  • 不刷新页面:使用 History API 进行页面导航时,不会触发页面的刷新,从而提供了更好的用户体验。
  • 可修改 URL:可以通过修改 URL 的hash值或使用新的 URL,来反映页面的状态变化。
  • 状态管理:结合前端路由框架,可以将页面的状态与 URL 关联起来,实现基于 URL 的状态管理。
  1. 用途:
  • 实现单页面应用(SPA):通过使用 History API,可以在单页面应用中实现页面的路由和状态管理,提供流畅的用户体验。
  • 改善用户体验:避免了页面刷新带来的用户体验问题,如页面内容的丢失、重新加载等。
  • 与服务器端配合:可以与服务器端进行配合,实现服务器端渲染(SSR)或渐进式渲染。
  1. 变化和更新机制: History API 提供了两种方式来修改 URL:
  • hashchange事件:通过修改 URL 的hash值来触发页面的导航。当hash发生变化时,浏览器会触发hashchange事件。
  • History.pushState()和 History.replaceState()方法:可以使用这两个方法来在浏览器历史记录中新增或替换条目,从而修改 URL。这两种方式不会触发页面的刷新。

通过监听hashchange事件或使用 History.pushState()和 History.replaceState()方法,可以在前端路由中根据 URL 的变化来加载不同的页面内容或执行相应的逻辑。同时,也可以通过回退和前进按钮来浏览历史记录中的不同页面状态。

需要注意的是,使用 History API 需要考虑一些兼容性问题,并且在某些情况下可能需要服务器端的配合来处理 URL 的变化。

四、 hash 和 history 的区别

比较 hash 和 history 的不同之处

hashhistory是前端路由中常用的两种方式,它们的主要不同之处在于以下几个方面:

  1. URL 格式:
  • hash方式使用 URL 的hash部分来表示路由状态,例如https://example.com/#/about
  • history方式使用正常的 URL 结构来表示路由状态,例如https://example.com/about
  1. 页面刷新:
  • hash方式的 URL 变化不会触发页面的刷新,因为浏览器认为hash部分是属于页面内部的。
  • history方式的 URL 变化可能会触发页面的刷新,除非使用了特定的技术(如 History API)来处理。
  1. 兼容性:
  • hash方式在所有的浏览器中都能正常工作,包括较旧的浏览器。
  • history方式需要支持 HTML5 History API 的浏览器才能正常工作,较旧的浏览器可能需要使用 polyfill 来实现兼容。
  1. 服务器端处理:
  • hash方式的 URL 变化不会被服务器端感知,因为服务器端只处理 URL 中不带hash部分的请求。
  • history方式的 URL 变化可以被服务器端感知,如果需要在服务器端进行处理,可能需要在服务器端配置相应的路由处理。

总体来说,hash方式更适合简单的单页面应用,而history方式更适合复杂的单页面应用或需要与服务器端进行交互的应用。在选择使用哪种方式时,需要根据具体的需求和项目的特点来进行考虑。

在应用场景中的选择

在应用场景中选择使用hash还是history,可以考虑以下几个因素:

  1. 兼容性:如果应用需要支持较旧的浏览器或移动设备,可能需要选择hash方式,因为它在所有的浏览器中都能正常工作。

  2. 用户体验:如果希望提供更好的用户体验,避免页面刷新,可以选择history方式。hash方式的 URL 中带有#符号,可能会让用户感到困惑。

  3. 服务器端处理:如果应用需要与服务器端进行交互,或者需要在服务器端进行路由处理,可能需要选择history方式。使用hash方式时,服务器端无法感知 URL 中的hash部分。

  4. 应用复杂度:如果应用比较简单,只有少数页面,可能选择hash方式就足够了。如果应用比较复杂,有多个页面或路由状态,可能需要选择history方式来更好地管理路由。

在这里插入图片描述

综合考虑以上因素,可以根据具体的应用场景和需求来选择使用hash还是history。在实际开发中,也可以先使用hash方式进行开发,然后在需要时再迁移到history方式。

文章来源:https://blog.csdn.net/weixin_42554191/article/details/135010187
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。