Hashtags(片断标识符）VS Javascript History API

哈希标签是对Twitter上的内容进行分类的一种方法，你指的是片段标识符。

使用片段标识符来指示通过Ajax加载什么内容是一个糟糕的想法。它们是一种脆弱的、对搜索引擎不友好的黑客攻击（除了双方都有更多的黑客攻击），并且依赖于JavaScript。

历史上的API是一个强大的系统，它实际上是为完成这项工作而设计的。它唯一的问题是浏览器支持，但（与片段标识符方法不同）它会优雅地降级为将直接传递给服务器的真实URI（Github就是这样做的）。

就连Twitter似乎也要转向历史API了。

新的历史方法对AJAX导航非常有用。例如，pushState或replaceState允许您更新浏览器的地址栏，以便用户看到一个干净的URL，而不是一个丑陋的标签。

然而，我相信您已经意识到，对新API的支持仍然有限。location.hash在这一点上得到了更广泛的支持，这意味着你必须为那些无法利用更新的window.history内容的浏览器编写一个哈希回退。

历史API是非常好的，只要正常链接在不支持它的浏览器中正常工作

您可以使用像History.js这样的库在这些浏览器中启用它。

更多信息在这里：这是关于哈希邦，哈希邦URL的副作用。

简而言之，URL很重要。URL是永远的，很酷的URL不会改变，最后：一旦你散列了，你就不能回去了。

我认为问题是什么是支持。你现在不能只使用History API，因为它不受IE支持。你需要像GitHub那样的后备解决方案。

您已经将"兼容性"列为第一个标准。由于历史API还没有得到所有主要供应商的支持（我在看你，微软），甚至在他们最新的版本中也不支持（IE9没有），这在很大程度上意味着你必须使用哈希。（这太糟糕了，但我们已经做到了。）不仅是微软，许多移动设备都在使用一两个版本的移动浏览器，所以仍然没有。