这个问题处理在浏览器中更改 URL 而不实际导航到该 URL 的问题。我还偶然发现了几个使用这种方法的网站，我发现它会让用户感到困惑/误导，我想知道为什么首先允许这样做。
问题：为什么允许代理/浏览器更改 URL 而不实际导航到该路径？允许这样做的好处是什么，而缺点是让用户感到困惑。
答案1
Web 应用程序早已能够仅使用 JavaScript 来完全更改页面内容。例如，在 Twitter 中，您可以从主时间线导航到个人资料，再导航到特定推文完全客户端，无需重新加载任何页面 – 只需基于 JavaScript 的更新。
问题在于，你无法复制、收藏或分享你当前所在的 URL。如果你从 开始https://twitter.com并打开推文或个人资料页面，你的地址栏仍然认为你位于https://twitter.com。你也无法点击“返回”按钮 - 你会离开整个应用程序。
#hash许多网站尝试通过仅更改URL 的一部分（用于内部页面链接）来解决这个问题，通常以使其看起来类似于真实路径的方式 - 例如单击 @stackoverflow 将其更改为https://twitter.com/#!/stackoverflow。
现在 URL 可以复制并可添加书签，但仍然存在问题 - 只有客户端 JS 可以理解它，而搜索引擎或禁用/阻止 JS 的浏览器甚至 wget/curl 等 HTTP 工具都无法理解它。对于所有这些工具和程序来说，# 后面的部分毫无意义（因为它指向动态 JS 生成的数据，而不是真实的 name= 或 id=）。
这就是为什么添加了 API 来通过 JS 生成“真实”历史事件的原因——它允许每个基于 JS 的页面拥有与真实基于服务器的页面完全对应的 URL。当您单击个人资料链接时，JS 会生成您在没有 JS 的情况下获得的相同页面（只是速度更快），因此它也具有相同的 URL。
如果你使用这个 API，你当然应该只生成服务器上实际存在并与真实 URL 对应的路径——就像在上面的例子中，当 JavaScript 将 URL 更改为 时https://twitter.com/stackoverflow，这是没问题的，因为这是一个可以稍后访问的真实页面，内容和所有内容都相同。只是碰巧该页面已加载通过 JS 而不是通过导航，但这种差异应该实际上是看不见的。
因此，“缺点是让用户感到困惑”只有在 API 为误用，例如生成服务器以后无法识别的 URL。