Next.js 什么时候该选，什么时候别选

一听到 React，很多人下意识就想到 Next.js。但真正该问的几乎从来不是”我要不要 React”，而是”我要不要一个把服务端渲染、客户端交互、边缘 runtime 揉在一起的混合框架”。如果答案是不要，那你就是给自己揽了一堆用不上的复杂度。这篇给你结论，也给你背后的数字，数据截至 2026 年 6 月。

一句话结论

• 站点表现得像 App，就选 Next.js 16：大部分页面有按用户的状态、要登录才能看、有 streaming / 实时 UI，或者需要请求时的服务端逻辑。
• 站点表现得像杂志，就选 Astro 5（或 Hugo / Eleventy）：博客、文档、官网这类 90% 以上能预渲染成 HTML 的页面。
• 选错的代价是实打实的：Next.js 跑在 Vercel Hobby 上禁止商用，且每月封顶 100 GB 带宽 + 100 万次函数调用，没有超额计费——撞到上限就直接暂停部署。
• 在决定之前先做下面那个”一个下午”的原型测试。哪个框架处理你这些页面类型时更不别扭，哪个就是对的。

2026 年的 Next.js 16 到底是什么

截至 2026 年 6 月，稳定线是 Next.js 16.2，它和大多数博客描述的那个 Next.js 已经很不一样了：

• Turbopack 成了默认，next dev 和 next build 都用它——Vercel 称开发启动快了约 400%、渲染快约 50%（对比旧的 webpack 路径）。
• 基于 React 19.2（View Transitions、useEffectEvent、<Activity> 组件），React Compiler 也转正为稳定，自动做 memoization。
• Cache Components（基于 Partial Prerendering 的 use cache 指令）是新的缓存模型——很强，但也是又一个要学的概念。
• App Router 是主线，Pages Router 进入维护期——还支持，但新功能只进 App Router。

这些能力确实强。但它奖励的是交互型产品面，不是一堆 Markdown 文件。几乎每篇独立开发者”我选了 Next.js”的复盘都同一个结尾：“我站 99% 是静态的，结果花了三个周末跟 Server Components 和缓存死磕。“

用 30 行代码看清差异

Next.js 真正发挥作用的仪表盘页面长这样——按请求拉数据、仅服务端鉴权、流式给客户端：

// app/dashboard/page.tsx —— RSC + 按请求拉数据 + 流式
import { Suspense } from 'react';
import { getUser } from '@/lib/auth';
import { getOrders } from '@/lib/db';

export default async function Dashboard() {
  const user = await getUser();          // 仅服务端、绑定到本次请求
  const orders = await getOrders(user.id);
  return (
    <>
      <h1>Hi {user.firstName}</h1>
      <Suspense fallback={<p>Loading recent orders…</p>}>
        <OrderList orders={orders} />
      </Suspense>
    </>
  );
}

而 Astro 真正擅长的内容页是这样——构建期生成一次、HTML 直出、默认零 JS：

---
// src/pages/blog/[slug].astro —— 构建期生成一次，HTML 直出
import { getEntry, render } from 'astro:content';
const post = await getEntry('blog', Astro.params.slug);
const { Content } = await render(post);
---
<h1>{post.data.title}</h1>
<Content />

核心页面长得像第一段，你需要 Next.js。绝大多数页面长得像第二段，就不需要。

决策对照表

信号	倾向 Next.js 16	倾向 Astro 5 / Hugo
页面构成	大部分按用户 / 交互	90% 以上静态、可预渲染
登录才能看的页面	占站点大部分	一个登录表单，顶多一个账户页
实时 / streaming UI	聊天、实时数据、分段输出	没有或极少
请求时逻辑	个性化 SSR、A/B 测试、地理	构建时就够了
发往浏览器的 JS	为 App 价值可接受	为 LCP / INP 越少越好
你的日常技术栈	本来就写 React	想要一套 HTML 优先的模型
托管现实	函数执行就是产品本身	静态 CDN，成本近乎零

如果大多数行你都打在左列，Next.js 值回票价。如果你打在右列，Next.js 就是要你搭进周末去维护的额外负担。

为什么托管成本比想象中更能拍板

选不选 Next.js 同时也是在选托管，因为 SSR 和 serverless 函数是按执行计费的。下面的数字截至 2026 年 6 月，正式使用前请再核对一下当前档位。

套餐	价格	含带宽	函数 / CPU	坑
Vercel Hobby	免费	100 GB	100 万次调用，4 小时 Active CPU	禁止商用；无超额，撞顶就暂停部署
Vercel Pro	$20 / 席位 / 月	1 TB	约 1,000 GB-小时 含量	超额带宽 $0.15/GB，Active CPU $0.128/小时
Firebase Hosting（Spark）	免费	10 GB/月 + 360 MB/天	Cloud Functions 仅 Blaze 档	允许商用；以静态为主

静态的 Astro / Hugo 站几乎全是 CDN 流量，所以即便一篇文章上了 Hacker News 首页，也稳稳待在免费档里。而 Next.js 的 SSR 站，每个在服务端渲染的请求都计费。同一个流量高峰，对 Astro 站可能一分钱不花，却能让 Hobby 部署暂停、或把 Pro 账单顶上去。如果你的内容很少按请求变化，那你就是在为一个用不上的 runtime 付钱。

两点实际提醒：Vercel 的 Hobby 档禁止商用，所以一个开始赚钱的副业项目，要么上 Pro，要么换别的托管。另外，如果你压根不想用 Vercel，next start 在便宜的 VPS 或容器里跑得也很好——只是运维得你自己扛。

做一遍”一个下午”原型测试

靠热度选框架很糟，靠摩擦感选很靠谱。花一个下午，按原型决定，别按博客决定。

1. 盘点页面类型。 把站上每个页面列出来，分成静态、按用户动态、交互式 App 三类。
2. 套 90% 规则。 90% 以上是静态，就停，先试 Astro 或其它 SSG。真撞墙了再回来考虑 Next.js。
3. 梳理动态页面。 对每个动态页，列出数据来源，判断要请求时渲染，还是构建时就够。
4. 估算执行成本。 免费档的按请求 SSR，在中等流量下就可能限速甚至暂停。拿你最重的那个页面对照上面的 Vercel 函数和带宽配额。
5. 同一个页面做两遍。 一个下午分别用 Next.js 16 和 Astro 5 做同一个代表性页面。摩擦感告诉你哪个模型更对你的胃口。
6. 到规模时重评。 先按原型决定，再在 50 页和 500 页时各重评一次——内容站后悔早期选了 SSR，往往不是在第一天，而是在后面。

容易踩的坑

• 把 Next.js 当 SSG 用。 能 output: 'export'，但同时砍掉 SSR、ISR、image optimization、middleware——到这一步，Astro 更干净也更快。
• 低估 App Router 的学习曲线。 服务端 / 客户端边界、use client 规则、还有新的 Cache Components 模型，Pages Router 老手照样栽。
• 默认 Vercel 永久免费。 Hobby 档禁止商用，而且只在你没撞到 100 GB 或 100 万次调用之前不限——撞到就暂停。
• 因为”大家都用”所以选它。 流行度不能替代工具和场景的匹配度。独立开发者的后悔，大多能追溯到这一句推理。

这篇适合谁，谁该跳过

用 Next.js 16 来做：如果你是做产品型站的独立开发者——SaaS dashboard、AI 聊天工具、市场平台——React 加按请求的服务端逻辑加 streaming 真的派得上用场。

跳过它：纯内容站——博客、文档、落地页，以 Markdown 更新为主、几乎不需要请求时计算。选 Astro、Hugo 或 Eleventy，把托管账单压到接近零。

FAQ

• 博客用 Next.js 是不是杀鸡用牛刀？: 基本是。博客 99% 是静态 HTML。Astro 5 发的 JavaScript 更少，Markdown 构建比它的旧管线快约 5 倍，部署也更便宜。只有当博客是套在真 App 上时，才考虑用 Next.js。
• Next.js 能纯静态输出吗？: 能，用 output: 'export'——但同时放弃 SSR、ISR、image optimization、middleware。如果你要的就这些，那就该问自己：为什么不直接用一个静态生成器。
• Next.js 会拖累 Core Web Vitals 吗？: 不是天然就拖累。但大客户端 bundle 和没做 memoization 的组件会。Astro 默认发近乎零 JS，LCP / INP 起跑就快一截；Next.js 16 的 React Compiler 和 Cache Components 用好了能把差距缩小。
• Pages Router 死了吗？: 没死。2026 年仍受支持、稳定，但处于维护期——新功能都进 App Router。新项目直接上 App Router，除非有具体的迁移理由。
• Next.js 一定要托管在 Vercel 上吗？: 不一定。next start 能跑在任何 Node 主机上（VPS、容器，或 Netlify、Cloudflare 这类平台）。Vercel 是用 App Router 功能最顺的路径，但你完全可以自托管，自己扛运维。

相关阅读

• Astro 和 Next.js 怎么选
• 静态站和 SSR 站如何选
• 什么情况下内容站不适合 Next.js

标签: #独立开发 #Next.js #建站策划 #对比 #入门

相关文章

独立开发 / 建站指南

2026 年 Next.js 内容站的 MDX 选型（next-mdx-remote 已归档）

next-mdx-remote 已于 2026 年 4 月归档，Contentlayer 早已停维护。本文给出 Next.js 16 内容站现在真正能用的几条路——RSC 上的核心 MDX、next-mdx-remote-client、mdx-bundler、contentlayer2、Velite，从 DX、构建时间、锁定风险逐一对比。

2026/05/23 #独立开发 #Next.js

独立开发 / 建站指南

Next.js 按需重新验证：Webhook 接法（2026）

编辑改个错字不该等重新部署。本文讲清楚 Next.js 16 App Router 怎么接 on-demand revalidation：webhook 路由、header 密钥、revalidatePath / revalidateTag / updateTag 怎么选、以及怎么验证真生效。

2026/05/23 #独立开发 #Next.js

独立开发 / 建站指南

App Router：你真正需要的 8 个概念

不用上 20 小时的课。这 8 个 App Router 概念就能解释你的 Next.js 16 代码为什么这样跑——含 async params 和缓存改动，正是老教程会踩坑的地方。

2026/05/15 #独立开发 #Next.js

独立开发 / 建站指南

Next.js 内容站 SEO：先排查这几个坑

Next.js 本身不破坏 SEO，但 Next.js 16 有几个真坑：异步 params、流式 metadata、动态路由。上线前用这套 metadata、sitemap.ts、view-source 清单过一遍。

2026/05/15 #独立开发 #Next.js

独立开发 / 建站指南

Next.js 部署到 Vercel：10 分钟上线流程（2026 年 6 月）

2026 年把 Next.js 部署到 Vercel：自动识别、环境变量、自定义域名、next/image 白名单、函数 region，以及让独立开发者卡半天的 App Router 几个坑。

2026/05/15 #独立开发 #Next.js

独立开发 / 建站指南

Next.js 图片优化：升级到 16 的检查清单

next/image 是你白拿的最大性能收益——但 Next.js 16 把 priority 标记为废弃、qualities 改成必填、缓存默认降到 4 小时。本文讲清楚要改什么。

2026/05/15 #独立开发 #Next.js