2025年技术栈选型：为什么我放弃 Next.js 回到服务端渲染？
先说背景。我做了五年中后台和内容站，去年把主力项目从 Next.js App Router 改造回 Express + EJS + htmx 的组合，不少同事觉得我在倒退。但这次回归不是拍脑袋，而是被百毫秒级差距和爆掉的内存逼出来的。
接下来聊聊具体对比。Next.js 看起来很香，但 App Router 把简单问题复杂化。我需要区分 Server Component 和 Client Component，不能直接传函数，还要记住 useActionState 的副作用、缓存失效时机、并行路由的 loading 边界。一个在线帮助文档项目，最后代码里到处是 use client，构建从 40 秒跳到 3 分 52 秒，本地热更新偶尔卡 5 秒。页面 TTFB 在无负载时都要 800ms 以上，Vercel 上冷启动更是超过 2 秒。更可怕的是 next dev 跑一周后内存占用稳定在 1.2GB，我 16G 的 MacBook 风扇像在吹唢呐。
作为对比，同一套页面用 Express 4.18 + EJS + htmx 2.0 重写后，部署在 2C4G 的云服务器上：TTFB 降到 60-90ms，构建时间其实就是 EJS 模板编译，几乎忽略不计，进程常年占用 180-220MB。交互靠 htmx 2.0 的 hx-get 和 hx-post，服务端返回 HTML 片段替换页面，没有前端路由、没有状态管理、没有 fetch 封装。代码规模从 45 个文件缩减到 21 个。用户感受不到交互差异，因为内容站的主要动作就是点链接、查表单和翻页，这些 htmx 全都能覆盖。
| 维度 | Next.js App Router | Express + EJS + htmx |
|---|---|---|
| 平均 TTFB | 820ms | 78ms |
| 开发构建耗时 | 232s | 1.5s |
| 常驻内存 | >1.2GB | ~200MB |
| 源码文件数 | 45 | 21 |
| 客户端 JS 体积 | 约 320KB | 约 35KB |
| SEO 支持 | 需要处理 SSR 边界 | 天然 HTML 输出 |
当然我说的是特定情况。如果项目里大量实时仪表盘、拖拽编辑器或者离线优先的功能，我依然推荐 Next.js 或 Remix。我的标准变成：首屏和核心路径超过 80% 是静态文本和表单操作，就用服务端模板方案；但如果超出 20% 的页面需要复杂状态同步，仍然用成熟的前端框架。不要以技术栈的新旧论英雄，要看它的复杂度是否换来实际用户价值。对于内部工具，团队只有两三个人，服务器成本不高，用传统 SSR 可以把 Bug 率压到极低，因为几乎不需要处理客户端缓存一致性的问题。
我真正想说的是，技术选型的核心矛盾从来不是语言的优雅，而是团队的平均能力模型和项目的生命周期。你们如果招不到能玩转 React Server Components 的工程师，那 Next.js 的进阶优化就永远躺在 PPT 里。别再被默认生成 create-next-app 的新潮绑架，先问问维护者能不能在凌晨三点定位到一个 use hook 抛出的水合错误。服务端渲染的这条老路没死，反而在复杂运营后台和内容型网站里变成一种极简的生存策略。所有技术都会过时，不会过时的，只是我们是如何处理产品的真实需求。