Nuxt适合一个人做网站吗？

先放一段配置，因为答案就藏在这里：

export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/tools/**': { swr: 3600 },
    '/app/**': { ssr: false }
  }
})

首页构建时生成、工具页缓存一小时、需要登录的部分纯客户端渲染——这三件事写在同一个文件里，不用自建渲染服务，也不用为每种页面搭一套构建流程。

一个人做站最怕的不是某个框架难，是同一件事要在三个地方配一遍。Nuxt 把这些收进了一处。

结论先给：适合，前提是你接受一个常驻的 Node 进程

Nuxt 帮你省掉的，恰好是一个人做站最耗时间且最不出彩的那部分：路由约定（放个 pages/tools/pdf-to-word.vue 就有 /tools/pdf-to-word）、服务端渲染与构建产物、<title> 和 meta 的按页设置（useSeoMeta）、以及 Nitro 那层把应用打包成能跑的产物。

代价也很清楚：默认部署形态是一个 Node 服务在跑，你要管它的重启、内存、日志。它不像纯静态站那样把 dist/ 丢给对象存储就完事。

所以判断标准变成了一句话：你的站有没有必须在服务端发生的部分？ 有（要读库、要鉴权、要按请求生成内容），Nuxt 值这个价；没有（全是客户端计算的工具页），纯静态生成器更轻。

routeRules 是为"页面矩阵"这种结构准备的

工具站的形态很特殊：几十上百个页面，每个页面内容基本不变，但都有交互。全量预渲染会让构建时间随工具数量线性变长，全量 SSR 又白白多出服务器开销。

swr: 3600 这种策略正好卡在中间——首次请求时渲染一次，之后一小时从缓存出。工具从 5 个加到 50 个，构建时间和运行时开销都不跟着涨。

配合 prerender: true 用在首页和高频页，剩下的走客户端。这套组合是 Nuxt 相对其他方案最实在的优势，多数框架要么只能全静态要么只能全 SSR。

内置 SEO 那部分能省掉一堆手工活

一个人做站，SEO 上的机械工作量不小：每个页面的 title、description、canonical、og 标签，sitemap 的生成，robots 的维护。

Nuxt 里 useSeoMeta() 写在页面组件里，SSR 时就进了 HTML；sitemap 和 robots 有官方模块接管，会跟着路由自动更新。这意味着新增一个工具页时，你不需要记得去任何清单里补一条。

这件事的价值在页面数量上去之后才显现。Omni Calculator 2026 年 6 月估算访问约 1429 万、支持 30 多种语言，它把计算器抽象成配置、页面由模板生成——人工维护每个页面的 meta 在这种规模下根本不可能。Nuxt 的路由即页面，是同一条思路的小规模版本。

10015.io 用了 Next.js，那不代表 Nuxt 是错的

10015.io 是 Next.js 加 styled-components，作者 Fatih Telis 连 UI 组件库都没装。它的做法说明了一件事：选型的关键不在框架名字，在"页面在服务端有没有内容"和"计算放在哪一端"。

10015.io 首页只有 Explore Tools 和 Product Finder 两个按钮，没有第三种动作。

这两个问题 Next.js 和 Nuxt 都能答好。真正决定体验差异的是别的：你更熟哪一个、生态里有没有现成的模块（Nuxt 有 content 模块、image 模块、sitemap 模块）、以及部署时你手上有什么。

还有一个差别在模块生态。Nuxt 官方维护了一批开箱即用的模块——内容管理、图片优化、sitemap 生成——装上就有，不用自己拼。Next.js 这边同类能力往往要自己引第三方库再配一遍。

一个人做站时，"不用自己拼"是有实际价值的，因为拼装部分不产生任何差异化。如果团队经验在 Vue 这边，硬上 React 系只会把时间花在重写熟悉的页面上。反之也一样。

部署有三种形态，选错会多花好几天

Nuxt 的 Nitro 层可以输出不同产物，这一步要在开工前想清楚，因为切换是有成本的。

Node 服务。 默认形态，跑一个 Node 进程，能用 SSR、能用服务端 API 路由。适合有动态内容、要读库的站。代价是要管进程守护、内存、日志轮转。

静态产物。 构建时把所有页面生成成 HTML 文件，丢给 CDN 或对象存储就行，不需要服务器。适合纯内容站和全客户端计算的工具站——这条路最省事，也最不容易出故障。

边缘运行时。 部署到边缘平台，按请求计费、自动扩容。流量小的时候几乎不花钱，但调试比本地 Node 麻烦，且有运行时的 API 限制。

选的依据还是那句：有没有必须在服务端发生的部分。没有就走静态产物，别为了"以后可能要"提前上 Node 服务。切换的成本不光在配置上，还在于你为 SSR 写过的那些代码在静态模式下要重新验证一遍。

什么时候该避开它

三种情况我不建议选 Nuxt：

一是站完全静态。几十个页面、内容不随请求变化，那 nuxi generate 出来的静态产物和直接用一个静态生成器差别不大，却多背了一份框架复杂度。

二是你对 Vue 不熟。JavaScript 基础扎实但没写过 Vue 的话，学习成本会落在业务之外的地方，而此刻业务才是要紧的。

三是部署环境不方便跑 Node。一些廉价虚拟主机只给静态目录和 PHP。这时候可以先在别处生成静态产物，或者干脆换方案——反代和静态服务那层怎么配，Nginx 的部分讲得更具体。

一周三个页面，比看评测准

先用 Nuxt 做一个三页的版本：一个首页、一个带表单的工具页、一个需要读数据的页面，把 routeRules 三种策略各用上一次，再部署到一台机器上跑一周。

一周之后你会知道两件事——构建时间对页面数量敏不敏感、Node 进程的内存稳不稳。这两件事比任何评测都准。你现在的部署环境，能长期养住一个 Node 进程吗？