SPA 巧妙地简化了应用程序开发的许多方面——将状态保存在一个地方，在主线程上，在导航中保持不变——这一事实是它们最大的优势之一，也是可预测的问题源泉。
例如：
- 您有一个搜索输入。您输入它，单击其他地方进行导航，下一页仍然具有输入中的文本。
- 你有一个可滚动的侧边栏。您向下滚动一半，单击某些内容，下一页仍然在最后滚动位置有侧边栏。
- 您有一个可扩展卡的列表。您展开其中一个，单击其他地方，下一页仍然展开了一张卡片。
管理状态是编写软件最困难的事情之一。在许多方面，状态管理的这一方面对 SPA 来说是一大福音。特别是，您不必考虑导航之间的持久状态；它只是自动发生。在 MPA 中，您必须在页面卸载时将此状态序列化为某种持久格式（LocalStorage、IndexedDB 等），然后在页面加载时重新水化。
另一方面，状态是导致内存泄漏的原因——我已经记录了一个令人作呕的 SPA 特有的问题。另外，状态偏离已知的良好初始值越远，您遇到错误的可能性就越大，这就是为什么行为不端的 SPA 通常只需要良好的刷新。
然而，有趣的是，MPA 导航并不总是在新状态下着陆。如前一篇文章所述，后向缓存（现已在所有浏览器中实现）使这个讨论更加细致入微。
在现代浏览器中，在同一来源的页面之间导航时，后向缓存（或简称 BF 缓存）会保留上一页和下一页的缓存。这大大减少了在标准 MPA 页面中来回导航时的加载时间。
但是这个缓存究竟是如何工作的呢？即使是 MPA 页面也可以是非常动态的。如果页面已经被动态修改，或者 DOM 状态发生了变化，或者 JavaScript 状态发生了变化怎么办？浏览器实际上缓存了什么？
事实证明，浏览器会记住很多东西。我在各种浏览器（桌面上的 Chrome/Firefox/Safari、Android 上的 Chrome/Firefox、iOS 上的 Safari）中对此进行了测试，并且在所有浏览器中都看到了相同的结果：按下后退按钮后保持完整页面状态。
现在，要明确一点：这并不能解决在正常向前导航中维护状态的问题。我上面所说的关于 MPA 需要序列化其状态的所有内容都适用于任何未缓存的导航。
有很多理由可以使用 SPA 技术、MPA 技术或两者的结合。一切都取决于您要构建的内容的需求和限制。
如果开发人员发现编写 SPA 比同等 MPA 更容易，那么 SPA 将继续构建。让 MPA 更有能力只是解决问题的一种方法：从另一端处理事情——例如改进的工具、指导和对 SPA 开发人员的教育——也可以朝着相同的最终目标努力。