与 hasbangs 相比，HTML5 Pushstate 有几个优势，事实上，Google 现在是 encouraging the use of Pushstate .唯一公开讨论的 Pushstate 缺点是非现代浏览器不支持它。但是，对我来说，Pushstate 在缓存方面似乎也有缺点。我可能是错的，因此这个问题。
在缓存页面方面，Pushstate 是否不如 Hashbangs？
这是一个 Pushstate 在缓存方面似乎很糟糕的案例。
推送状态
Bob 导航到
eg.com/page1，整个页面被下载、呈现和缓存。Bob 单击一个按钮，下载并缓存
eg.com/json/page2。浏览器处理 JSON 并重新呈现 Bob 页面的部分内容。
Pushstate 将显示的浏览器地址更改为
eg.com/page2。Bob 关闭浏览器，然后重新打开，直接访问
eg.com/pushstate2。完整页面已下载、呈现和缓存。*
*-尽管理论上它已经以 eg.com/json/page2 的名义在缓存中可用
哈希帮
Alice 导航到
eg.com/#!page1，下载并缓存eg.com/index.html。eg.com/json/page1已下载并缓存。浏览器处理 JSON 并呈现 Alice 的页面。
Alice点击一个按钮，
eg.com/json/page2被下载并缓存，显示的浏览器地址变为eg.com/#!page2浏览器处理 JSON 并呈现 Alice 的页面。
Alice 关闭浏览器，然后重新打开并直接访问
eg.com/#!page2。 与 Pushstate 不同，没有下载任何内容，所有内容都从缓存中加载。
总结
我有很多类似的案例，问题是这是否确实有效，我可能遗漏了一些导致我得出错误结论的东西。在缓存页面方面，Pushstate 是否不如 Hashbangs？
最佳答案
我认为 pushstate 较差，但如果您正确构建 SPA 页面，差异应该不会很大:
假设您正在使用最新的框架之一，您的 index.html页面应该比较小一些<script>标签(webpack、systemjs 等框架)。
使用这些标记引用的 js 文件确实会正常缓存，因此这两种方法之间的唯一区别是获取 index.html。对于每个 pushstate url，而不是在 hashbang 模式下获取一次。
我从以下问题中得到了这个想法: https://webmasters.stackexchange.com/questions/65694/is-this-way-of-using-pushstate-seo-friendly
关于ajax - 在缓存方面，Pushstate 是否不如 Hashbangs？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27356774/