browserHistory和hashHistory的区别 #152

Anuluca     Date : 2024-08-22   Tags : 3

browserHistory 和 hashHistory 是在前端路由中常用的两种历史模式，它们的主要区别在于 URL 的结构和工作方式。它们通常与 React Router 或类似的路由库一起使用。以下是它们的详细区别：

1. browserHistory（HTML5 History API）

browserHistory 使用的是 HTML5 的 history.pushState 和 history.replaceState API。它们允许你在不重新加载页面的情况下改变浏览器的 URL。

特点：

• URL 结构：使用的是“干净”的 URL，没有 # 符号。例如：https://example.com/about。
• 导航体验：URL 看起来与传统服务器渲染的 URL 类似，用户体验更加自然。
• 服务器配置：通常需要服务器端支持，例如，在访问特定路径时（如 /about），服务器需要配置为返回同一个 index.html 文件，否则直接访问可能会导致 404 错误。

优点：

• 更加美观和现代化的 URL。
• 方便与 SEO 结合（虽然现代应用多为 SPA，SEO 主要靠其他方式实现，但对于混合模式有好处）。

缺点：

• 需要服务器配置，以避免刷新时的 404 错误。
• 在某些旧浏览器中（特别是 IE9 及以下），需要 polyfill 才能工作。

示例：

1
2
3

import { createBrowserHistory } from 'history';

const history = createBrowserHistory();

2. hashHistory（基于 URL 哈希）

hashHistory 使用的是 URL 的 # 部分来模拟不同的路径。这种方式不依赖服务器的配置，适用于更早期的浏览器。

特点：

• URL 结构：URL 中包含 # 符号。例如：https://example.com/#/about。
• 导航体验：所有路由都发生在 # 符号之后，浏览器只会关注 # 之前的内容，不会触发服务器请求。
• 无需服务器配置：因为 URL 的哈希部分不会被发送到服务器，所以即使刷新页面，服务器也不会返回 404 错误。

优点：

• 不需要服务器端配置，前端可以直接使用。
• 兼容性好，在更老的浏览器中也能良好运行。

缺点：

• URL 不美观，存在 # 符号。
• 不适合 SEO，因为搜索引擎通常不解析 # 后面的内容。

示例：

1
2
3

import { createHashHistory } from 'history';

const history = createHashHistory();

总结：

• browserHistory：提供了更好的用户体验和现代 URL 结构，但需要服务器配置来避免刷新时的 404 错误。

• hashHistory：更简单、更兼容老浏览器，无需服务器配置，但 URL 中带有 # 符号。

什么时候使用哪种模式？

• 小型应用或无需特别优化的项目：hashHistory 可能是一个更简单的选择，因为它无需额外的服务器配置。

• 大型或注重用户体验、SEO 的应用：browserHistory 更加合适，尽管它需要额外的服务器配置来处理 URL 路径。

PS：服务器要怎么配置才能支持browserhistory？

当前端应用调用第三方 API 而不会遇到跨域问题时，通常有几种常见的原因和机制在起作用。这些机制主要是由浏览器的同源策略（Same-Origin Policy）和跨域资源共享（CORS, Cross-Origin Resource Sharing）规则决定的。

1. 第三方 API 使用了适当的 CORS 头

大多数现代 Web API 都会启用 CORS 以允许跨域请求。当你的前端代码调用第三方 API 时，如果该 API 的服务器配置了正确的 CORS 头信息，它就会允许来自你的网站的请求。

• Access-Control-Allow-Origin: 这个头可以指定哪些域名被允许访问资源。例如，如果 API 响应中包含 Access-Control-Allow-Origin: *，它就会允许任何域名访问这个资源。

• Access-Control-Allow-Methods: 指定被允许的 HTTP 方法，例如 GET、POST 等。

• Access-Control-Allow-Headers: 指定哪些请求头被允许在实际请求中使用。

例如，第三方 API 的响应可能包含以下头信息：

1
2
3

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization

这种设置确保了跨域请求能够顺利进行，而不会被浏览器拦截。

2. 通过 JSONP 实现跨域

在 CORS 普及之前，开发者常用 JSONP（JSON with Padding）来解决跨域问题。JSONP 是一种通过 <script> 标签来实现跨域数据传输的技术。因为 <script> 标签不受同源策略的限制，所以可以用它来加载外部的 JavaScript 文件，包括动态生成的 JSON 数据。

JSONP 的缺点是它只支持 GET 请求，而不支持其他类型的 HTTP 请求（如 POST, PUT, DELETE 等）。

3. 代理服务器

有时，第三方 API 可能不支持 CORS。在这种情况下，开发者通常会使用一个中间的代理服务器。前端发送请求到同源的代理服务器，而代理服务器再去请求第三方 API，并将结果返回给前端。因为前端和代理服务器之间是同源的，所以不会遇到跨域问题。

4. 使用服务器端调用

另一种方式是将 API 请求完全移到后端服务器。前端并不直接与第三方 API 通信，而是向自己服务器的端点发送请求，由服务器代为请求第三方 API 并返回结果给前端。这样也避免了前端跨域问题，因为从服务器到第三方 API 的请求不受浏览器的同源策略限制。

5. WebSockets

WebSockets 通信是一种全双工通信协议，允许客户端和服务器之间持续通信。一旦 WebSocket 连接建立后，它就不再受到同源策略的限制。不过，在初始握手阶段，服务器仍然需要设置正确的 CORS 头来允许连接。

6. 第三方 API 位于相同域名或子域名下

在某些情况下，第三方 API 可能位于与你的前端应用相同的域名或子域名下。在这种情况下，因为它们属于同源策略定义的同一源，调用这些 API 自然不会有跨域问题。

7. 跨域脚本资源共享 (Cross-Origin Resource Sharing - CORS)

如果你在调用第三方 API 时，API 提供方配置了 CORS 并允许来自你的域名的请求，那么跨域问题可以通过浏览器的 CORS 机制解决。

8. 浏览器的默认行为或忽略跨域限制

在某些情况下，某些浏览器（或浏览器插件）可能会允许特定类型的跨域请求。例如，某些插件可能会忽略 CORS 限制，或者某些特殊类型的请求（例如图像、CSS、脚本等静态资源）在某些浏览器中可能不完全遵循同源策略。

总结

通常，第三方 API 能够被成功调用而不报跨域问题，往往是因为 API 提供方配置了合适的 CORS 头信息，允许你的域名访问它们的资源。在现代 Web 开发中，CORS 是最常见的解决跨域问题的方法。其他方法如 JSONP 和代理服务器仍然存在，但其使用频率已相对较低，特别是在较新项目中。