我是一个实用主义者，所以我会试着从成本和收益的角度来看待这件事。
请注意，对于我给出的任何缺点，我都认识到它们是可以解决的。这就是为什么我不把任何事情看得非黑即白，而是成本和收益。
优势
更容易的状态跟踪-不需要使用cookie，表单提交，本地存储，会话存储等来记住2个页面加载之间的状态。
每个页面(页眉、页脚、logo、版权横幅等)上的样板内容在每次典型的浏览器会话中只加载一次。
切换“页面”时没有开销延迟。
缺点
Performance monitoring - hands tied: Most browser-level performance monitoring solutions I have seen focus exclusively on page load time only, like time to first byte, time to build DOM, network round trip for the HTML, onload event, etc. Updating the page post-load via AJAX would not be measured. There are solutions which let you instrument your code to record explicit measures, like when clicking a link, start a timer, then end a timer after rendering the AJAX results, and send that feedback. New Relic, for example, supports this functionality. By using a SPA, you have tied yourself to only a few possible tools.
Security / penetration testing - hands tied: Automated security scans can have difficulty discovering links when your entire page is built dynamically by a SPA framework. There are probably solutions to this, but again, you've limited yourself.
Bundling: It is easy to get into a situation when you are downloading all of the code needed for the entire web site on the initial page load, which can perform terribly for low-bandwidth connections. You can bundle your JavaScript and CSS files to try to load in more natural chunks as you go, but now you need to maintain that mapping and watch for unintended files to get pulled in via unrealized dependencies (just happened to me). Again, solvable, but with a cost.
Big bang refactoring: If you want to make a major architectural change, like say, switch from one framework to another, to minimize risk, it's desirable to make incremental changes. That is, start using the new, migrate on some basis, like per-page, per-feature, etc., then drop the old after. With traditional multi-page app, you could switch one page from Angular to React, then switch another page in the next sprint. With a SPA, it's all or nothing. If you want to change, you have to change the entire application in one go.
Complexity of navigation: Tooling exists to help maintain navigational context in SPA's, like history.js, Angular 2, most of which rely on either the URL framework (#) or the newer history API. If every page was a separate page, you don't need any of that.
Complexity of figuring out code: We naturally think of web sites as pages. A multi-page app usually partitions code by page, which aids maintainability.
我再次承认，这些问题中的每一个都是可以解决的，只是需要付出一定的代价。
但总有一天，你把所有的时间都花在了解决问题上，而这些问题本来是可以避免的。这又回到了益处以及它们对你的重要性上。
