SPA的缺点是什么？不利于SEO，首屏打开速度更慢。同时，与业务模块之间的关联紧密，不好拆分。对于桌面网站，大都跑在网络环境较好的情况下，优势并不明显，而劣势却完全凸显。SSR可以部分解决问题，但是SSR性能并非最优，并且成本也不低。因此算不上最优解。而且很多桌面网站在SPA技术之前就已经搭建好了，相关的技术问题也成熟并够用，配合Gulp之类的也能很好解决工程化的问题。
SPA框架要实现得优雅，离不开现代化的API（浏览器特性或语言特性）。对此，移动端的环境比桌面端好不少，很多桌面端网站的兼容性要求的包袱大大限制了框架的应用。SPA框架的历史比绝大部分桌面网站的历史短，网站还没发展到需要被SPA革命的时候，后接手项目的开发者的重构动力还没达到非得使用SPA的程度。
国内微信和 QQ 等应用内置浏览器（至少 iOS 是这样）的毒瘤属性，如果你是用 pushState 改变的 url，那么分享出去的时候还会是最初点进去的那个 url，这就导致，如果你想让你的内容能被正确分享，不要分享出去的时候以为是 A，结果别人点开是 B，那么你至少对「具体内容页面」（比如一篇文章、一个帖子）不能采用框架内部路由，而只能用最原始的 href 改变 url。很多网站没有做成SPA并不是技术原因，而大多数是业务划分和遗留代码的问题。
很多网站不同的业务或者产品对应不同的业务和开发部门，因此他们会独立开发自己业务的网页（目前基本上都选择SPA了），然后再去和主站集成，这里“集成”一般都会直接在主站添加入口链接。有时候选择多页面模式也是刻意为之，如果业务复杂多样，在一个SPA上加载太多东西势必会影响网站性能，将不同业务做成多个SPA，对用户体验影响并不大，但是会简化业务的独立开发、部署和维护。
另外就是遗留代码的问题。前端技术更新太快，一般新成立的项目都会选择使用新的框架语言，遗留代码都是旧的技术问题，如果想要做成SPA，那意味要在一个页面加载多个框架，必然会影响性能，因此会选择多页面，然后再做旧页面到新页面的迁移。
目前比较多被提及的前端微服务化，是希望多个前端服务能够整合到一个SPA上，但是由于技术问题目前还是有局限。网站设计的相关东西都是不断更新的，如果出现一些新的东西也有可能没有那么快适用，所以还要选择合适的。
本文地址：//qlpinke.com//article/2442.html
