将此归类为“我无法相信以前没有人注意到这一点”或“我一定是错过了什么”的类别：
似乎如果在iOS上执行简单的window.history.pushState，除非它是响应于用户手势，否则位置栏不会更新。状态本身已被推送（您可以通过点击返回按钮看到）。
这是我能想出来重新创建问题的最小测试用例：
http://thelink.is/history-api-ios-bug
在支持History API的桌面浏览器中，您应该看到每秒钟URL在位置栏中更改为/0、/1等。在iOS上——使用iPhone（运行iOS 4.3）和iPad（运行iOS 4.3.3）进行测试——位置栏不会更新，但点击返回按钮将带您到正确的前一个位置（在测试用例上将404，因为没有后端逻辑处理这些URL）。
有什么想法？解决方法？需要抱怨和拥抱吗？
更新：此问题已在iOS 5中修复。
var i = 0;
var locationUpdateInterval = setInterval(function(){
window.location.hash = i;
i++;
}, 1000);
若要捕获当iOS应用程序中的某些内容更改该位置，或者如果他们有指向您的应用程序中特定页面/面板的永久链接时触发的事件：
// named function on purpose for later
function hashchange() {
var pageId = location.hash.substr(1); // drop the # symbol
// do something with pageId
}
window.onhashchange = hashchange;
// onload - if there's a hash on the url, try to do something with it
if (location.hash) hashchange();
很遗憾，在 iOS 上我们无法使用 pushState/popState，但这和不允许触发全屏视频以及下载视频或音频内容是一样的安全机制。也就是说，你不能通过脚本来自动完成这些操作，用户必须手动开始（方式各异）。
关于 Android，问题也非常相似，因此这个解决方法（应该）也适用于 Android。
如果你需要桌面浏览器支持，大多数浏览器都支持 onhashchange，但是，你猜对了，IE 的支持不如其他浏览器，所以你可以用插件来模拟它（不过需要 jQuery...）：http://benalman.com/projects/jquery-hashchange-plugin/
希望这有所帮助。
onhashchange事件onpopstate事件，不像其他浏览器replaceState调用替换后返回正确的状态/ bug reportonpopstate一旦页面已加载/ change recommendationpushState和replaceState调用中的我找到了以下内容：
当推送的位置包含一个哈希符号时，地址栏将被更新。 因此，这将起作用：
window.history.pushState(data, title, 'a/new/url#');
但是window.location对象不会被更新，因此您需要将推送的URL保存到一个变量中，并在需要推送位置时使用该变量，而不是使用window.location。
已在Android上的Safari进行测试。
我发现了一个有点可行的黑客技巧。原来，如果你在history.pushState之后立即更改哈希值，地址栏就会更新。像这样：
window.history.pushState(data, title, 'a/new/url');
window.location.hash = 'new';
将位置栏更改为http://example.com/a/new/url#new。这会引入另一个问题，因为哈希成为了自己的历史记录条目。所以你仍然需要监听onHashChange事件。
这有点复杂，但有些人真的非常讨厌哈希bang URL，并且非常强烈地表达了他们的意见。所以这是值得的。