History.pushState 和 History.pushState 之间有什么区别？位置.hash？

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

3 年前已关闭。

社区审查了是否在 3 年前重新开放此问题，并将其关闭：

原始关闭原因未解决

Answer 1

location.hash 比history.pushState 方法。

pushState 方法的优点是您可以将状态绑定到历史条目。

如果您不需要此状态对象，我建议使用 location.hash 属性，以便与旧版浏览器具有更好的兼容性。

location.hash = 'new-hash';
console.log(history.state); // null or undefined

history.pushState({extraData: "some state info"}, '', 'new-hash'); //<---
console.log(history.state); // [object Object] = {"extraData": "some state info"}

Answer 2

Pushstate 是未来。它更好是因为：

1. 它看起来更干净。
2. 在重新访问深层链接时，您实际上可以显示真实的服务器端数据来支持 SEO 和 Facebook Open Graph（两者都会发送蜘蛛来抓取页面的 html）之类的东西。
3. 服务器无法访问哈希标签数据，因此您在服务器日志中看不到它，因此它可以帮助某些人进行分析。
4. 它有助于解决哈希标签问题。例如，我重写了 Nginx，将访问我的应用程序的用户重定向到相同的 https url。它适用于所有浏览器，但 Safari 会将您重定向到没有哈希值的域（太烦人了）！
5. 实际上，您可以使用哈希标签来实现深层链接到长页面的部分。
6. 对于不支持推送状态的浏览器，您可以回退到使用真实的 HTTP 后端请求，或者您可以回退到使用哈希标签。两者都需要额外的实现，但只需做一些工作即可轻松实现。

有关更多信息，请参阅 Github 设计师的演讲：http://warpspire.com/talks/responsive/

Answer 3

这是一个相当老的问题（在本回复时已超过 5 年），但对现有回复的很多评论都要求根据“当前”状态进行更新。

事情是这样的：

所有主流浏览器都支持 HTML5 的 PushState。如果您也支持旧版浏览器，history.js 提供了一个很棒的polyfill，让您可以使用pushState原生并让它轻松回退到旧版浏览器的旧版 URL。然而，现在原生支持pushState并不意味着它就是正确的选择。

有一个非常重要的观点在任何旧的答案中都没有提出，那就是哈希 URL 和 PushState URL 不仅在显示方式上不同，而且实际上在工作方式上也不同。两者之间的这种根本区别可能会导致您选择其中之一。

PushState 更漂亮、更干净，可用于在您的网站/应用程序中完全伪造导航。例如，GitHub 用它来隐形地替换所有导航。当您单击其网站上的任何链接时，JavaScript 用于拦截该单击并将其转换为 AJAX 请求，该请求会更新页面内容而无需加载新页面，而地址栏中的 URL 会发生更改以匹配之前的内容取来的。 这就是pushState 的用途。

就 GitHub 而言， http://mysite/page1 和 http://mysite/page2 都是有效的 URL。它们是具有“真实”内容的“真实”链接，并且最初访问任一页面都会通过传统的 MVC 方法。 GitHub 在现代浏览器中使用 pushState 进行导航，但并不要求它 - 即，pushState 被用作“功能添加”（在他们看来），以在导航时带来更好的用户体验。当您复制浏览器地址栏中的链接时，您正在复制通过 javascript & 形成的链接。 PushState，但仍然是真实有效的链接。

但是，如果您从头开始创建一个单页应用程序并且没有使用 MVC 框架，那么您实际上只有一个页面，特别是如果您没有使用动态后端（即内容全部通过 javascript 检索） ，从未由服务器生成）。在这种情况下，如果您在哈希 URL 上使用 PushState，则需要处理浏览器中的 URL 不是真实 URL 的情况。我会举例说明。

用户加载您的单页应用程序： http://mysite/mainpage

此时，浏览器栏包含真实的链接您的应用程序，并将用户带到他们当前看到的相同视图：主页。现在，他们单击一个链接，将进入一个显示某些活动详细信息的“页面”。此时，您想要更新位置栏以指示状态的变化。您可以使用哈希 URL，并且您的地址栏看起来像 http://mysite/mainpage#charts/1或者你使用pushState并欺骗它成为 http://mysite/mainpage/charts/1

如果你使用PushState，即不是真正的链接。通过浏览器的后退/前进按钮导航效果很好，用户将从主页转到地址栏和应用程序中的详细信息页面（假设您正确处理状态更改），但如果用户将此链接添加为书签或者复制粘贴链接来分享，需要额外的服务器端巫毒。

您需要将 /mainpage/charts/1 的请求重定向到 /mainpage，然后使用 JS 解析实际 URL 并执行预期的状态更改操作。服务器重定向是绝对需要的。如果没有可编写脚本的 http 服务器，您无法在 AWS 或本地磁盘上托管此页面。

现在，如果您使用哈希网址，则用户将看到并与之交互的网址将是 http://mysite /mainpage#/charts/1 这是一个有效的真实网址。浏览器知道只有一页，无论用户复制并粘贴链接还是为其添加书签，您只需在 JavaScript 中处理哈希状态，不需要任何服务器端魔法即可使事情正常工作。

似乎没有人提到的是pushState 和哈希链接并不相互排斥。 PushState 只是一个 API，用于操作用户可见的浏览器位置，并在现代浏览器中实现可靠的后退/前进导航。它没有说明您的 URL 方案应该是什么样子。

2017 年，Google 和几乎所有其他支持 JS 的机器人都可以理解哈希 URL 并很好地遍历它们。 Google 希望您使用#! SEO 令人厌恶
最大化的目的，但即使您不这样做，您的网站也可以正常导航。

正确的答案是使用最适合您需求的东西。如果您有真实的 URL 并且想要在它们之间伪造导航，请使用 PushState 并继续（对于较旧的浏览器，可以选择使用 polyfill）。但如果您有一个单页应用程序，请不要假装不这样做（除非您有充分的理由）。使用哈希 URL 可以让您的生活更轻松，并且不会引入不必要的问题，然后使用 PushState 操作这些哈希 URL 以利用更好的后退/前进支持。。

Answer 4

history.pushState 比 location.hash 更好。但这是 HTML5 的功能。所以最好有一个像下面这样的后备方法。

if (typeof(window.history.pushState) == 'function') {
    window.history.pushState(null, path, path);
} else {
    window.location.hash = '#!' + path;
}

Answer 5

我同意其他答案，但这里有一些支持 location.hash 的论点：

• 它适用于所有浏览器，包括 Internet Exploder^TM
• History.pushState 是一个正在开发的标准，如果用户在新窗口/选项卡中打开链接，API 将来可能会发生变化
• ，哈希 URL 可确保加载页面不需要服务器请求（如果正确）设置了缓存标头）
• 服务器配置是很简单，因为服务器看到的只是没有哈希部分

编辑的 URL：我忘记了

• 带有标签的 URL，您可以使用真实的链接（a href）。因此您不必设置点击侦听器，这提高了性能并减少了代码大小。

Answer 6

window.location.hash 与 HTML5 History.pushstate 的优点/缺点很大程度上取决于您希望页面降级的具体程度。

在这里，您可能对两种不同场景中的优雅降级感兴趣：

第一个是未启用 JavaScript 的客户端，或者是访问您网站的自动机器人/爬虫。从 SEO 的角度来看，这一点尤其重要。如果您的网页/网络应用程序使用哈希 URL，则这些最终用户将无法获得通过这些链接提供的内容。如果您仅通过哈希 URL 提供内容部分且没有后备，这绝对是一个问题。但是，如果您使用哈希标签链接来修改应用程序状态，那么如果页面降级，应用程序状态就不会保留任何意义，这绝对不是问题。

作为一个示例，请考虑这样一个场景：您的页面在选项卡式布局小部件的三个选项卡中包含三个文本部分。现在有两种可能的情况：在第一种情况下，您将在页面加载期间加载所有内容 - 选项卡式小部件将仅用于隐藏其他部分并显示特定部分。因此，如果您在用于构造选项卡拇指的链接中使用哈希 URL，则您仅使用它们来更改客户端应用程序状态。当 javascript 关闭/不可用时，只是用于构造选项卡式布局的 javascript 不会运行，并且所有内容立即可用 - 一个合理的优雅回退。在这种情况下，不同的应用程序状态根本不存在，因此哈希 URL 降级为仅指向 html 中的锚点 - 预期目的。
如果您在这种情况下使用 html5 Pushstate，而不是 hash-urls，那将是一个坏主意。用户可能会为特定选项卡的链接添加书签的原因。因为您的服务器必须获取该 url 并向用户呈现他所期望的客户端状态。这对于客户端应该负责自己的状态管理的瘦服务器架构来说并不好。您当然可以忽略服务器端的这一方面，并​​让客户端在页面加载时一开始就检查 url，然后切换到适当的应用程序状态。但这仍然不是一个好主意，因为您的服务器端路由系统关心它应该忽略的额外 url 片段的开销，因为从美学角度来看，它根本不应该担心该片段。这完全符合 hash-url 的设计要求，强烈建议使用它们。如果在这三个部分中，当单击特定选项卡拇指时动态加载文本，那么使用 hash-url 并不是一个好主意。原因是如果 JavaScript 不可用，用户将无法访问链接的内容。这对于 SEO 来说尤其不利。在这种情况下，如果您在服务器端处理 url（在正常情况下会被“劫持”和“ajaxified”）以使内容通常可用，那么从最终用户体验和 SEO 的角度来看，这都是非常好的。

第二种情况是客户端的浏览器过时，不支持 html5 推送状态。虽然上述观点仍然成立，但此外我还认为，强迫没有 Pushstate 的用户与 no-javascript 具有相同程度的降级是不合理的。许多最终用户根本不知道为什么他们会收到降级版本。

我建议您不要总是遵循使用最新技术的教条动机，并根据您的使用场景确定最佳选择。

Answer 7

目前，所有现代浏览器都支持 pushState。因此，pushState 比 location.hash 更好，但它是 HTML5 功能。

所以，location.hash 并没有消亡，事实上它还会存在很长很长一段时间。

使用此功能的一个好方法是使用支持 pushState 的库，但也可以优雅地降级为使用 location.hash。

示例 - https://github.com/browserstate/history.js

此外，location.hash 对于跳转到命名锚点仍然有用。
pushState 将为构建 Web 应用程序提供巨大帮助。我期待着使用它。

Answer 8

我个人更喜欢pushState，因为它使URL 看起来更漂亮，而且我认为这对于用户体验很重要。

您可以使用 history.js polyfill< 来将 history.pushState 与哈希回退结合使用< /a> 如果您想使用pushState，但又不想遇到旧版浏览器支持的问题。

Answer 9

我在该线程中没有看到一个非常小的差异：

设置 window.location.hash 将强制立即滚动跳转到文档中的新哈希元素（至少在我使用的浏览器中） ）。如果您想要平滑滚动，但也希望网址栏中的哈希值更新/更改，则必须使用 window.history.pushState，如下所示：

document.getElementById(id).scrollIntoView({ behavior: "smooth" });
window.history.pushState(null, null, "#" + id);