上周和一个前同事约饭，他现在在一家创业公司带前端团队。

聊到一半他突然问我：“我们准备把项目重构成 Next.js。上服务端渲染，你觉得怎么样？”

我放下筷子的观点是，“你们现在遇到什么坑了要重构？”

从他挠挠头来看，“坑倒是没有…，就是现在出去面试，人家都问有没有 Next.js 经验。我们不用会不会显得技术栈太旧了。”

“那你们产品要 SEO 吗？使用者网络环境咋样，不过，”

“使用者都在一二线城市。网速挺好的，SEO 的话…，产品得登录才能用，搜索引擎也爬不到。说起来，”

我看着他，不知道该说什么。

又一个被技术流行绑架的老同事。

一、SSR不是银弹。它是一把双刃剑

这两年，Next.js、Nuxt.js确实火得不行。打开技术社区，满屏都是“从CSR迁移到SSR后FCP提高50%”、“SSR才是前端正确的打开方式”。但不知道你有没有发现，很少有人告诉你：为了这点性能提高。你和你团队接下来半年要填多少坑。

. 服务器账单：以前不要钱。现在要钱了 —— 痛点：成本失控与老板灵魂拷问

纯静态页面放OSS上，流量不大时一年可能就几百块。上了SSR呢，话说回来，

• 你需要一台服务器，或者云函数实例
• 你需要考虑并发，一台扛不住要上负载均衡
• 你还要担心服务器宕机。得配监控、告警、容灾

实际案例：我一个朋友的项目，上了SSR后第一个月，云账单从300涨到了3000。老板拿着账单问他：“使用者感受到变快了吗？多出来的钱能从收入里赚回来吗？”他答不上来，更扎心的是后来发现大部分使用者都是从首页跳详情页，**首屏调整的收益根本覆盖不了成本**。

. 复杂度转移：以前是纯前端问题。现在是全栈问题 —— 痛点：认知负荷爆炸、Hydration报错、降级策略无从下手

// CSR时代：岁月静好
function UserProfile {
const = useState
useEffect => {
fetch.n
},)
return 

{user?.name}
}

// SSR时代：噩梦开始
export async function getServerSideProps {
try {
const controller = new AbortController
const timeoutId = setTimeout => controller.abort。3000)
const res = await fetch(`http://internal-api/user/${params.id}`,{
signal的观点是，controller.signal
}).catch => null)
clearTimeout
if {
// ❌ 降级策略怎么写？页面直接500还是降级CSR？return { props: { user: null。fallback: true } }
}
const user = await res.json
return { props: { user } }
} catch {
// ❌ 服务端报错，使用者看到什么？return { notFound: true }
}
}
function UserProfile {
// ❌ 防止hydrate报错的防御性代码
const = useState
useEffect => { setMounted },)
if return 

加载中...
return 

{user?.name}
}

前线心声："自从上了SSR。 我不仅要写React，还要会配Nginx、懂PM2、会分析内存泄漏。工资没涨，责任翻倍，" —— 某前端同事朋友圈实录 数据在服务端取，**取不到怎么办？页面直接500还是降级成CSR？** 接口超时了**是等待还是超时返回？** **服务端和客户端状态怎么对齐？** 一不小心就 hydrate mismatch 报错。原本简单的逻辑，**全是防御代码**，业务逻辑一点没变复杂。

. 开发体验的割裂感 —— 痛点：到处写 typeof window!话说回来，== 'undefined'、三方库不兼容、动态导入包裹

// CSR时代
const width = window.innerWidth
const token = localStorage.getItem
// SSR时代：满屏防御
const width = typeof window!说起来，== 'undefined'?window.innerWidth : undefined
const token = typeof window!== 'undefined'?localStorage.getItem : null
// 三方库报错 "window is not defined" → 动态导入包裹
const Chart = dynamic => import,{ ssr: false })
// 路由跳转小心 → 没有 history API
// localStorage/sessionStorage 全部封装 Hooks 用 useEffect 延迟读取

• 第三方库如果不兼容服务端渲染 → 必须动态导入包裹；
• localStorage/sessionStorage不能直接用 → 必须封装 Hooks 延迟到 useEffect；
• 路由跳转要小心 → 没有 history API；
• 原本简单的逻辑 → 写一堆防御代码做安检。

二、你真的需要SSR吗？问自己三个扎心问题

再看问题一，你的产品靠搜索引擎吃饭吗？

如果答案是 "否"搜索引擎根本爬不到，**SEO就是伪需求**。别拿SEO当借口，**你只是想让简历里多一行Next.js**。

• ✅ 需要SEO:             内容站/博客/官网/电商商品页/落地页 
• ❌ 不需要SEO: 后台管理/需登录B端/私密社区/游戏H5/App内嵌页  

问题二的观点是，首屏速度真的慢到不能忍了吗？

很多时候觉得慢。**不是CSR不行**，是代码写得太糙。调整代码比换架构性价比高得多！老实说，**别为了那微乎其微的几百毫秒调整搭进去半年维护成本。话说回来，** 💰💸💰💸💰💸💰💸💰💸💰💸...

// ❌ 慢在哪？useEffect => {
fetch.n.n => fetch) // ❌串行！.n.n => fetch) // ❌串行！new Image.src = 'big-banner.png' // ❌无WebP/懒加载
document.head.appendChild // ❌同步阻塞三方脚本 }。)

// ✅ CSR也能快 useEffect => { Promise.all,fetch,fetch]) // ✅并行！// ✅图片WebP + 懒加载 + CDN script.async = true // ✅异步加载三方 },) // 🚀 Vue2项目纯CSR调整：首屏3.2s → 1.1s！没动架构没重构没加班，🚀