# 网站上线后，服务器成本真的很高吗？

URL: https://caijiao.org/posts/126
Source: docs/posts/126.md
Description: 让成本失控的不是访问量，是"每个请求都要在服务端干活"。10015.io 50 多个工具几乎不请求服务端；Omni Calculator 1429 万访问仍把页面速度看得比加机器重要。把活搬到浏览器里，是最彻底的一刀。

不高——但这个答案有个前提，而且这个前提在很多人那里是默认不成立的。

"上线之后服务器会很贵"这个判断，隐含着一个假设：用户的每个请求都要在服务端算一遍。上传文件、处理、返回结果，CPU、内存、带宽、磁盘全都跟着用户量涨。在这个假设下，成本高是必然的。

问题是这个假设本身可以推翻。10015.io 有 50 多个工具，原则是**几乎所有工具在客户端运行，极少请求服务端**。它的请求里绝大多数只是"把 JS 和 wasm 文件发出去"，服务器做的事和 CDN 差不多。工具从 1 个加到 50 个，开销几乎不动。

所以准确的答案是：**成本取决于你把多少活留在了服务器上，而不是取决于你有多少用户。**

## 会持续涨的那一项：上传的文件留了多久

成本失控最常见的形态不是 CPU 爆了，是磁盘悄悄涨满了。

一旦文件要上传到服务器，你就多出三份开销：入站带宽、处理时的 CPU 和内存、以及落盘之后的空间。前两项是瞬时的，第三项会累积——只要你不主动删，它会一直涨，而且涨上去之后通常没人敢删（怕删掉用户还在用的东西）。

TinyWow 的处理方式很干净：**上传的文件 1 小时后自动删除**。这句话对用户的价值是隐私，对成本的价值是让存储变成了一个固定值而不是增长曲线。250 多个工具、月访问在 180 万到 230 万之间，如果每个文件都留着，磁盘早就撑不住了。

配套做法是在架构上把"必须落盘"的场景压到最少——能在浏览器里处理的就别上传。

## Omni Calculator 的做法：宁可优化页面，也不加机器

Omni Calculator 2026 年 6 月的估算访问量约 1429 万、支持 30 多种语言。它把计算器抽象成配置、页面由模板生成——这个设计本身就是成本控制：页面是模板产出的静态内容，不是每个请求现算的。

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

*Omni Calculator 首页还有一个 Discover Omni 板块，自我介绍是「用计算揭示世界的惊人真相」。*

更说明问题的是它的态度。广告负责人 Alexander Utz 说过，页面速度对他们没有商量余地，整个增长都依赖 SEO，Core Web Vitals 直接影响排名。

注意这里的因果：他们优化页面速度，首要动机是排名而不是省钱。但结果是一样的——一个把每个字节都抠过的站，带宽和 CPU 开销必然低。成本控制在这里是性能优化的副产品。

顺带一句，页面能不能被正常抓取和索引，比省钱更要紧。[Google Search Central](/google-search-central/) 里关于索引的部分值得先过一遍，一个跑得飞快但没被收录的站，省下的钱没有意义。

## 拿 3.4 万会话算一遍账

terrific.tools 那组数字可以直接用来做成本校验：30 天 3.4 万次会话、4.1 万次浏览，广告收入 174.41 美元，折合每千次会话 6.89 美元。

按每千次会话 6.89 美元的收入倒推，服务器成本必须远低于这个数，否则项目在账上就是负的。而它的实际结构是——展示广告加一个桌面版应用，没有服务端重计算的迹象。

再看它做了 12 个月才等到这个数字。也就是说，在这 12 个月里，成本必须低到可以让一个人无条件地持续投入。低成本在这里不是省钱技巧，是项目能活到变现那一天的前提。

## 三个会突然变贵的信号

**一是 SSR 没有缓存。** 每个请求都要在服务端跑一遍渲染，用户量一涨 CPU 就顶住。缓解办法是渲染一次缓存一段时间，而不是每次重算。

**二是数据库查询没走索引。** 数据量涨到一定规模后，一次全表扫描能拖垮整台机器。这类问题在早期完全看不出来，等到发现时往往已经在影响响应了。

**三是静态资源没走缓存或没压缩。** JS 和 wasm 文件是工具站的主要体积，没开压缩、没设长缓存头，带宽会白白翻几倍。这几项在 [Nginx](/nginx/) 里都是几行配置的事，漏掉纯属浪费。

## 把活搬到浏览器里，是最彻底的一刀

三种信号里前两种是优化，第三种是配置。真正改变成本结构的是另一个动作——把计算从服务端搬到客户端。

具体路径就是 [WebAssembly](/webassembly/)：把编解码器、压缩算法、ffmpeg 这类现成的 C/C++ 库编译成 wasm，在浏览器里跑。服务器从此只做一件事——发文件。

这一刀砍下去之后，"服务器成本高不高"这个问题会失去对象：你的机器变成了静态文件服务器，账单里最大的一项是带宽，而带宽又可以被 CDN 缓存吃掉大半。

## 一个更实用的记账方式

与其每月看账单总额，不如看两个比值：每千次会话的服务器成本，以及每千次会话的收入。

terrific.tools 那边收入侧是每千次会话 6.89 美元，目标是 10 美元。成本侧如果能算出自己的数字，两个一比就知道这个模式成不成立——成本侧的比值只要远小于 6.89，这个站在账上就是健康的，规模涨上去也不会失控。

算不出这两个比值，说明你还没把流量和成本对应起来，这时候讨论"贵不贵"没有依据。

## 剩下的判断

成本不是不能高，是应该高得有理由。如果一个站每个请求都必须在服务端干活——要读别人的数据、要调用付费 API、要跨用户聚合——那成本就是业务的一部分，涨了说明业务在涨。

怕的是另一种：成本涨了，但用户量没涨，或者涨的成本没有换来任何新能力。出现这种情况时，先别急着升级套餐，去数一遍有多少请求本可以在浏览器里跑完。你的站里，这一刀还剩多少没砍？