react-router：为什么首选 browserHistory 而不是 hashHistory？答案

【问题标题】：react-router: Why the preference for browserHistory over hashHistory?react-router：为什么首选 browserHistory 而不是 hashHistory？
【发布时间】：2023-03-30 12:22:02
【问题描述】：

我对 React 比较陌生；如果这是一个非常幼稚的问题，我们深表歉意。

browserHistory 有哪些技术优势使其优于hashHistory？例如，使用History API 是否会显着提升性能/效率？

文档声明browserHistory 是recommended，尽管这是以additional server config 为代价的，并且需要通过basename 为不同的服务器硬编码或配置您的基本 URL。

hashHistory“正常工作”，但是，不管提供文件的基本 URL 是什么。无需服务器配置。捆绑您的应用程序，从服务器上的任何 URL/路径托管它，一切顺利。

如果文档进一步解释为什么建议browserHistory，即使它涉及更多复杂性，它可能会很好。

【问题讨论】：

标签： react-router

【解决方案1】：

在某些情况下 hashHistory 很好 - 除非您开始处理需要知道原始请求的完整 URL 的服务器端逻辑。

浏览器不会在任何 HTTP 请求中发送 URL 的 #hash 部分。

因此，当用户请求页面时，服务器端（即 NodeJS）将不知道 URL 中的 #hash 是什么。

一个很好的例子是用户尝试加载需要登录的页面（通过 oAuth 等）。在用户被带到一个单独的网站进行身份验证之前，您的应用程序的服务器端会告诉身份验证供应商在成功登录后将用户重定向到哪个 URL（通常它是请求的原始 URL，因为大多数网站都是这样做的）。如果您要使用 hashHistory - 服务器端将只知道 # 符号之前的位，并将用户重定向到您的应用程序的主页而不是子页面用户想要加载。

我希望这是有道理的。

【讨论】：

好的，但在您的示例中，“采取到单独的网站进行身份验证”的操作是由客户端的路由系统完成的——通过某种 navigateTo 操作——反过来可以调整它以获得# 重定向前的部分 url 并将其转换为 ?urlAfterLogin "real" 参数 ?

【解决方案2】：

browserHistory 优于 hashHistory 的一个原因是它更适合部署和生产。 hashHistory 通过在 url 末尾添加一个唯一键来“工作”，并通过使用这些键来跟踪您当前的会话来为此创建一个“历史记录”。

没有#，browserHistory 看起来更简洁，但为了进行此设置，您需要配置您的服务器，使其能够处理您打算提供的URL。

希望有帮助！

【讨论】：

【解决方案3】：

browserHistory 比 hashHistory 更受欢迎的技术优势是什么？

它允许你有一个服务器端后备：

允许访问的第一个页面使用 HTML 进行初始化（而不是必须使用 Ajax 获取所有数据），从而提供更好的性能
表示网站即使在when JS fails 也能正常工作（这对搜索引擎来说也更好）。

这是以必须以与客户端代码相同的方式编写服务器端代码来构建页面为代价的。没有它，使用历史 API 客观上会更糟……但是 URL 非常主观地更好，所以很多人在没有服务器端的情况下这样做。

【讨论】：