我想使用window.location.hash或更新 URL history.pushState。
每种方法的区别和优点是什么？
history.pushState 和 location.hash 有什么区别？
IT技术
javascript
html
url
pushstate
fragment-identifier
2021-02-23 00:12:36
6个回答
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"}
Pushstate 是未来。更好，因为：
- 它看起来更干净。
- 在重新访问深层链接时，您实际上可以显示真实的服务器端数据以支持诸如 SEO 和 Facebook Open Graph（两者都发送蜘蛛来抓取页面的 html）之类的东西。
- 服务器无权访问哈希标签数据，因此您不会在服务器日志中看到它，因此它有助于分析。
- 它有助于解决哈希标签问题。例如，我有一个 Nginx 重写，将访问我的应用程序的用户重定向到相同的 https url。它适用于所有浏览器，但 Safari 会将您重定向到没有哈希值的域（太烦人了）！
- 您实际上可以使用哈希标记来表示其含义，深层链接到长页面的部分。
- 您可以回退到对不支持推送状态的浏览器使用真实的 HTTP 后端请求，或者您可以回退到使用哈希标记。两者都需要额外的实现，但只需少量工作即可轻松实现。
有关更多信息，请参阅 Github 设计师的演讲：http : //warpspire.com/talks/responsive/
history.pushState比 好location.hash。但它是一个 HTML5 功能。所以最好有一个像下面这样的后备方法。
if (typeof(window.history.pushState) == 'function') {
window.history.pushState(null, path, path);
} else {
window.location.hash = '#!' + path;
}
这是一个相当古老的问题（在此回复时为 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 或本地磁盘上托管此页面。
现在，如果您使用哈希 url，那么用户会看到并与之交互的 URL 将是http://mysite/mainpage#/charts/1 并且这是一个有效的真实 url。浏览器知道只有一页，无论用户是复制和粘贴链接还是为其添加书签，您只需要在 javascript 中处理散列状态，不需要任何服务器端魔法来使事情工作。
似乎没有人提到pushState 和 hash 链接不是相互排斥的。pushState 只是一个 API，用于操作用户可见的浏览器位置并在现代浏览器中实现可靠的后退/前进导航。它没有说明您的 URL 方案应该是什么样子。
在 2017 年，谷歌和几乎所有其他支持 JS 的机器人都能理解哈希 URL 并很好地遍历它们。Google 希望您使用 #! 出于 SEO 最大化目的而令人憎恶，但即使您不这样做，您的网站也可以正常导航。
正确的答案是使用最适合您需要的任何东西。如果你有真实的 URL 并且想要在它们之间伪造导航，请使用 pushState 并继续（对于旧浏览器可以选择使用 polyfill）。但是如果你有一个单页应用程序，不要假装没有（除非你有很好的理由）。使用哈希 URL 使您的生活更轻松，不会引入不必要的问题，然后使用 pushState 操作这些哈希 URL 以利用更好的后退/前进支持。
我同意其他答案，但这里有一些赞成的 论点location.hash：
- 它适用于所有浏览器，包括 Internet Exploder TM
- history.pushState 是一个发展中的标准，API 未来可能会发生变化
- 如果用户在新窗口/选项卡中打开链接，哈希 URL 可确保加载页面不需要服务器请求（如果设置了正确的缓存标头）
- 服务器配置很简单，因为所有服务器看到的都是没有哈希部分的 URL
编辑：我忘记了一个
- 使用主题标签，您可以使用真实链接 (
a href)。因此，您不必设置点击侦听器，从而提高性能并减少代码大小。