# 一个网站应该自己开发还是使用现成CMS？

URL: https://caijiao.org/posts/132
Source: docs/posts/132.md
Description: 判断点不在会不会写代码，而在页面是否由数据批量渲染。Omni Calculator 把计算器抽象成配置、页面由模板生成；TinyWow 250 多个工具各占一个 URL，这种结构套 CMS，改一次模板会同时动到几千个页面。

给一个网站选技术栈，我第一件事不是看框架，是数页面：这些页面是编辑一篇篇写出来的，还是由数据一份份渲染出来的。两种站长得很像，答案却完全相反。

## Omni Calculator 的 1429 万访问，不是 1429 万个手写页面

Omni Calculator 在 2026 年 6 月的估算访问量约 1429 万，覆盖 30 多种语言。它的做法是把一个计算器抽象成一份配置——公式、单位、默认值、说明段落——页面由模板渲染。新增一个"房贷计算器"不是新建一个页面，是往配置里加一条。

![Omni Calculator 官网首页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页写着 3925 个免费计算器，Finance 一个分类就占 616 个。*

这个结构决定了它不该用 CMS。CMS 的模型是"每篇内容是一条记录"，字段靠自定义字段或插件拼；当页面有几百上千个、且结构高度一致时，CMS 里的"内容"其实只是一份结构化数据，套一层 CMS 等于把数据塞进 post_meta，改一次模板要担心影响几千个页面，还得手工跑全站回归。

配置加模板的写法反过来：配置进 Git，模板改动走 CI，一次提交就能看到全部页面的 diff。这也是为什么它敢把页面做成预渲染的静态页——生成量再大，速度也不受实时查询影响。

## 10015.io 用 Next.js，但明确不装 UI 组件库

10015.io 的作者 Fatih Telis 是伊斯坦布尔的前端开发者，做这个站的起因很朴素：书签栏里那个叫 Tools 的文件夹太长了。2020 年上线，现在 50 多个工具，选型是 Next.js + styled-components，刻意不用组件库。

不用组件库这件事，放在工具站的语境里才说得通：50 多个工具，每个交互都长得不一样——上传区、滑块、画布、表格、代码高亮——组件库提供的统一视觉规范在这里是负资产，你得先花时间覆盖它的默认样式，最后得到一堆 `!important`。这是 [React](/react/) 组件化在工具站上最容易被误用的地方：组件化的目的是复用，而工具站里真正能复用的只有布局和按钮。

更关键的是运行位置：几乎所有工具都在客户端跑，极少请求服务端。既然要管理的是逻辑而不是文字，CMS 的内容管理能力对它毫无用处——它甚至没有一个"后台"可供编辑。

## 静态生成把运维压到近乎为零，这是自写方案最被低估的一块

自己写不代表自己扛服务器。把页面在构建期就渲染成 HTML，部署就变成了三步：CI 跑一次构建、把产出的静态文件推上去、刷新 CDN 缓存。

这套东西的运维内容和 CMS 完全不是一个量级。没有 PHP 或 Node 进程要盯，没有插件要跟随安全公告更新，没有后台登录页被撞库，也没有因为某个插件和另一个插件版本不合而白屏的半夜。WordPress 站点最耗人的从来不是写文章，是插件更新之后不知道哪里坏了——而这件事的排查成本，和有几百个页面要改，是同一类成本。

需要一点动态能力时也不用推倒重来：表单提交、订阅计数、短链跳转这类活，用几个独立的接口函数就够了，它们和页面生成互不干扰。真正必须实时渲染的场景其实很窄——内容因人而异（登录后看到不同数据）、或者要展示实时库存和价格。工具站几乎都不在这两类里。

## CMS 真正划算的地方，是有第二个人要改内容

一个人维护、内容以 Markdown 写在仓库里，提交即发布，比登录后台点保存更快，还能 diff。我只在下面几种情况装 CMS：有非技术的共同作者要写稿；需要定时发布和草稿流转；需要媒体库管理大量图片；需要让编辑自己填 SEO 字段而不用找我改代码。

代价也要算进去。CMS 意味着一个数据库：备份策略、大版本升级、插件冲突、被扫描器盯上的登录入口，都是长期支出。一个 [SQLite](/sqlite/) 就能装下的项目，为了后台编辑功能去养一套独立的数据库服务，是我踩过最典型的坑。

还有一种折中做法值得单列：内容仍然写在 Git 仓库里（Markdown 或 JSON），但给它配一个轻量的管理界面，写作者看到的是一个表单，保存背后是一次提交。这样既保留了 diff 和回滚，又不用让对方学 Git。它适合"内容需要被第二个人改，但那个人其实也能接受一点约束"的情况，比直接上 WordPress 轻，比纯命令行友好。

## 一个容易被忽略的成本：模板站改版会成倍放大

配置加模板还有个副作用，要在选型时就想清楚：改一次模板等于同时改掉几百个页面。这既是它的优势，也是它的风险——一次字段命名调整，可能让一半页面的标题变成空的。

对应的工程习惯是：给配置加类型校验和必填校验，构建时跑一遍全页面快照比对（改版前后各生成一批 HTML，diff 一遍关键区块）。这几件事在 CMS 里通常由插件解决，但插件能覆盖的校验远没有自己写的规则贴合你的数据结构。

## 三条具体的判断线

页面数：少于 30 个且结构各不相同，用 CMS 省事；超过 100 个且结构高度一致，用配置加模板。

作者数：只有你一个人，Git 提交比后台快；两个人以上、其中有人不写代码，CMS 才开始回本。

数据落点：内容不需要落库——纯前端工具、静态页——就没必要为它准备数据库；内容需要被查询、被关联、被多人同时编辑，才轮到 CMS 出场。

三条里破了两条就别硬撑 Markdown，一条都没破时装 CMS 只是给自己多找一份运维工作。前端交互那一层倒是可以早做决定，[JavaScript](/javascript/) 的写法一旦定下来，后面换模板引擎也不会推翻。

我现在的默认答案是：工具站和计算器站自己写，内容站超过 50 篇再考虑 CMS，而且优先考虑无头 CMS 加静态生成，别急着把渲染也交出去。

---

*文中 Omni Calculator 访问量为 2026 年 6 月第三方估算数据；10015.io 技术选型与作者信息来自其官网及作者公开分享。*