哪一個更好？使用片段標識符...Hashtags（片段標識符）VS Javascript歷史API
http://www.alinkthatdoesnotwork.com/#!/dir1/dir2/file.html
...或新的Javascript歷史API？
https://github.com/examplethatdoesnotwork/project/src/script.js
還是應該同時使用？ （通過回退）
方面：
Hashtags是對Twitter上的內容進行分類的一種手段，您的意思是片段標識符。
使用片段標識符來指示通過Ajax加載哪些內容是一個可怕的想法。他們是一個破解是fragile, search engine unfriendly (except with more hacks on both sides) and depends on JavaScript。
歷史API是一個強大的系統，實際上被設計來完成這項工作。它唯一的問題是browser support，但（與片段標識符方法不同），它將優雅地降級爲真正的URI，並直接傳遞到您的服務器（即what Github does）。
即使Twitter似乎是about to switch to the history API。
歷史API是大大優選的，只要正常鏈接通常在瀏覽器中工作的是不支持它。
您可以使用庫如History.js在這些瀏覽器中啓用它。
更多的信息在這裏：It's About The Hashbangs，Side Effects of Hash-Bang URLs。
簡而言之，URL很重要。 URL永遠不變，酷的URL不會改變，最後：一旦你hashbang，你不能回頭。
我認爲問題是什麼是支持。目前您無法單獨使用History API，因爲它不受IE的支持。您需要像GitHub那樣的後備解決方案。
您已將「兼容性」列爲您的第一條標準。既然歷史API isn't yet supported by all major vendors（我在看你，微軟），甚至在他們最近的版本（IE9沒有它）中也沒有，這幾乎意味着你必須使用散列。 （這太糟糕了，但我們現在是這樣。）不僅僅是微軟，許多移動設備使用的是其移動瀏覽器的一個或兩個版本，但仍然沒有。
新的歷史記錄方法對於AJAX導航非常有用。例如，pushState或replaceState允許您更新瀏覽器的地址欄，以便用戶看到乾淨的URL而不是醜陋的標籤。但是，我相信你知道，對新API的支持仍然有限。在這一點上，location.hash得到了更廣泛的支持，這意味着你必須爲不能利用較新的window.history內容的瀏覽器編寫散列回退。