我盯着浏览器里那片空白快十分钟了。Network面板里那个名字带ssr的请求，状态码是200，响应体却只有一行字：{ "code":0,"data":[]}。这比报错更让人发慌——服务器明明活着，却像在装死。

SSR，服务端渲染，听起来高大上，说白了就是让服务器把HTML拼好了再发给浏览器。我接手这个项目时，前任留下的注释写着“SSR优化，性能提升300%”。可当我真的打开页面，首屏白屏时间还是快三秒。数据呢？接口在服务端调了，渲染在服务端做了，可用户看到的还是转圈圈。

问题出在细节上。我翻代码，发现服务端拿到数据后，先塞进一个全局变量window.__INITIAL_STATE__，然后模板引擎开始拼字符串。拼到一半，遇到一个v-if判断，条件依赖用户登录态。服务端不知道用户登没登录，只能默认false。结果客户端一接管，发现状态不对，整个组件树重新渲染一遍。白屏时间没省，反而多了一次无谓的DOM diff。

后来我学聪明了，不再迷信“SSR=快”这个公式。真正该做的是区分场景。像商品详情页这种静态内容多的，SSR确实香，爬虫能抓到完整HTML，用户也能秒开。可一旦涉及强交互的模块，比如购物车数量角标、实时聊天窗口，服务端拼出来的那点HTML反而成了累赘——客户端还得花时间把事件监听绑上去，绑定之前用户点啥都没反应。

有个朋友在电商公司，他们做过一次实验：把首页全部改成CSR（客户端渲染），只留首屏骨架屏。结果呢？SEO流量掉了四成，但用户平均停留时长反而涨了。因为页面“活”得更快，用户能立刻滑动、点击，而不是等一个静态页面慢慢“复活”。这让我明白，SSR不是银弹，它只是SEO和首屏体验的妥协品。

现在我再看到ssr这个请求名，第一反应不是“性能优化”，而是先问一句：这数据服务端真的需要吗？如果只是为了让爬虫看到几条商品信息，完全可以用预渲染方案，生成静态HTML扔到CDN上。真正的SSR，应该留给那些“不加载就没法看”的核心内容——比如一篇文章的正文，或者一个需要登录才能访问的仪表盘。

代码还在那里，{ "code":0,"data":[]}。我加了行日志，发现服务端请求数据库超时了，返回空数据。但页面没报错，因为模板引擎把空数组渲染成了“暂无内容”。这比白屏更可怕——用户以为真的没数据，其实只是服务端慢了一拍。最后我改了配置，超时时间从2秒提到5秒，又在模板里加了加载中状态。页面好多了，但我知道，这治标不治本。

SSR这事儿，跟修水管差不多。漏水了，你得先找到哪儿漏，而不是把整个水管都换掉。有时候，问题根本不在服务端渲染本身，而在你把它用在了不该用的地方。技术选型这事儿，光看性能报告没用，得自己跑一遍真实场景，看看用户到底卡在哪儿。