最近领导沉迷上了 next.js 。我懂一个情节，就是刚学会某项技能，总是想把它用在方方面面，比如他这次想在中台上用 ssr ，理由是 next.js 生态很好，使用方便，基础设施，（尤其是 next auth ）能节省很多时间。 我的看法是，ssr 、ssg 这类技术对于现代网站(中古 seo)除外，简直是本末倒置，彷佛 csr 一文不值，而忽略了 csr 的许多优势 页面切换速度，（ csr 切换页面时，只需要向服务端请求一个短短的 api ，整体速度迅速且流畅，而且消耗的带宽很小）而 ssr 、ssg 每次切换页面，都要重新拉取完整的页面，ssr 甚至都重新计算，速度和带宽占用都不如 csr 表现出色。ssr 、ssg 的 css 问题，如果使用了 css-in-js 这类的 ui 框架，那就更惨了，如果不进行 css 预提取，那将导致客户端闪屏(css 由 js 计算，而 js 异步加载，页面在 js 加载完毕后会闪动一下以应用新的 css 样式)，如果进行的 css 的提前烘培，则客户端会拉取双倍的 css(即拉取的预烘培的 css ，以及后续 js 里的 css)。 我实在不理解为什么还有人鼓吹 ssr 和 ssg 的性能，难道仅仅就是把 js 的一部分执行时间放在服务器上，性能就变好了？是服务端的性能好了，还是客户端的性能好了。。这中间导致的 FOUC 、css double 、page reload 以及带宽带来的损失，又该向谁说理去 CSS, ssr, ssg, csr
@rozbo 你首先要分清 SSR CSR SSG 和 SPA MPA 是不同的。SSR 优化的是首次加载。对于 SPA 来说，SSR 只有首次加载才有效，后面的切换和 CSR 没有什么不同，对于 MPA 来说会比较复杂一些，但是 MPA 你简单理解成 SPAxN 就好了。 对于任何 CSS-IN-JS 来说，都不可能没考虑到 CSS DOUBLE 的问题，如果有这个问题，说明这个 CSS-IN-JS 库很久没更新不支持 SSR 而已。不过有的 CSS-IN-JS 在 SSR 下面有性能问题倒是真的。所以我现在选择 TailwindCSS 。或者 ZeroRuntime 的。你们领导没让你们用 Qwik 搞恢复性就偷笑吧，SSR 已经是很保守的策略了。
