🤍 前端开发工程师（主业）、技术博主（副业）、已过CET6
🍨 阿珊和她的猫_CSDN个人主页
🕠 牛客高级专题作者、在牛客打造高质量专栏《前端面试必备》
🍚 蓝桥云课签约作者、已在蓝桥云课上架的前后端实战课程《Vue.js 和 Egg.js 开发企业级健康管理项目》、《带你从入门到实战全面掌握 uni-app》
文章目录
- 一、引言
- 介绍 hash 和 history 的背景
- 为什么需要了解 hash 和 history
- 二、 hash 的基本概念
- 三、 history 的基本概念
- 四、 hash 和 history 的区别
- 比较 hash 和 history 的不同之处
- 在应用场景中的选择
一、引言
介绍 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。
-
什么是 hash： 在前端路由中，
hash是指 URL 中#后面的部分。它可以用来在不刷新页面的情况下，通过改变hash值来进行页面的导航。 -
hash 的特点和用途：
- 不发送给服务器：浏览器在访问带有
hash的 URL 时，不会将hash部分发送给服务器。这意味着服务器端无法获取或处理hash值。 - 只在客户端生效：
hash的变化只在客户端生效，不会导致服务器端的请求或页面刷新。 - 简单且兼容性好：
hash的实现相对简单，并且在大多数浏览器中都得到了很好的支持，包括旧版本的浏览器。 - 用于前端路由：在单页面应用（SPA）中，前端路由可以利用
hash来进行页面的切换。通过监听hashchange事件，可以根据hash的变化来加载不同的页面内容。
- hash 的变化和更新机制： 当用户点击链接或在浏览器中手动修改
hash值时，浏览器会触发hashchange事件。在hashchange事件中，可以通过获取当前的hash值来进行相应的页面更新或路由处理。此外，还可以通过使用 History API（如 HTML5 的 History API）来实现更高级的前端路由功能，提供更好的用户体验。
三、 history 的基本概念
在前端路由中，history指的是 History API，它是 HTML5 提供的一种用于管理浏览器历史记录的接口。通过 History API，可以在不刷新页面的情况下，修改 URL 的hash值或使用新的 URL，实现页面的导航和状态管理。
- 特点：
- 不刷新页面：使用 History API 进行页面导航时，不会触发页面的刷新，从而提供了更好的用户体验。
- 可修改 URL：可以通过修改 URL 的
hash值或使用新的 URL，来反映页面的状态变化。 - 状态管理：结合前端路由框架，可以将页面的状态与 URL 关联起来，实现基于 URL 的状态管理。
- 用途：
- 实现单页面应用（SPA）：通过使用 History API，可以在单页面应用中实现页面的路由和状态管理，提供流畅的用户体验。
- 改善用户体验：避免了页面刷新带来的用户体验问题，如页面内容的丢失、重新加载等。
- 与服务器端配合：可以与服务器端进行配合，实现服务器端渲染（SSR）或渐进式渲染。
- 变化和更新机制： 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 的不同之处
hash和history是前端路由中常用的两种方式，它们的主要不同之处在于以下几个方面：
- URL 格式：
hash方式使用 URL 的hash部分来表示路由状态，例如https://example.com/#/about。history方式使用正常的 URL 结构来表示路由状态，例如https://example.com/about。
- 页面刷新：
hash方式的 URL 变化不会触发页面的刷新，因为浏览器认为hash部分是属于页面内部的。history方式的 URL 变化可能会触发页面的刷新，除非使用了特定的技术（如 History API）来处理。
- 兼容性：
hash方式在所有的浏览器中都能正常工作，包括较旧的浏览器。history方式需要支持 HTML5 History API 的浏览器才能正常工作，较旧的浏览器可能需要使用 polyfill 来实现兼容。
- 服务器端处理：
hash方式的 URL 变化不会被服务器端感知，因为服务器端只处理 URL 中不带hash部分的请求。history方式的 URL 变化可以被服务器端感知，如果需要在服务器端进行处理，可能需要在服务器端配置相应的路由处理。
总体来说，hash方式更适合简单的单页面应用，而history方式更适合复杂的单页面应用或需要与服务器端进行交互的应用。在选择使用哪种方式时，需要根据具体的需求和项目的特点来进行考虑。
在应用场景中的选择
在应用场景中选择使用hash还是history，可以考虑以下几个因素：
-
兼容性：如果应用需要支持较旧的浏览器或移动设备，可能需要选择
hash方式，因为它在所有的浏览器中都能正常工作。 -
用户体验：如果希望提供更好的用户体验，避免页面刷新，可以选择
history方式。hash方式的 URL 中带有#符号，可能会让用户感到困惑。 -
服务器端处理：如果应用需要与服务器端进行交互，或者需要在服务器端进行路由处理，可能需要选择
history方式。使用hash方式时，服务器端无法感知 URL 中的hash部分。 -
应用复杂度：如果应用比较简单，只有少数页面，可能选择
hash方式就足够了。如果应用比较复杂，有多个页面或路由状态，可能需要选择history方式来更好地管理路由。
综合考虑以上因素，可以根据具体的应用场景和需求来选择使用hash还是history。在实际开发中，也可以先使用hash方式进行开发，然后在需要时再迁移到history方式。
