# Nuxt适合一个人做网站吗？

URL: https://caijiao.org/posts/122
Source: docs/posts/122.md
Description: Nuxt 的 routeRules 能按路由分别指定预渲染、SWR 和纯客户端渲染，正好对上工具站"页面要静态、交互要客户端"的结构。代价是要养一个 Node 进程，纯静态的项目可以直接出静态产物，Omni Calculator 的模板生成思路也一样。

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

```ts
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 官网首页截图](/images/2026-09/10015.io.png)

*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](/javascript/) 基础扎实但没写过 Vue 的话，学习成本会落在业务之外的地方，而此刻业务才是要紧的。

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

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

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

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