网站上线后,服务器成本真的很高吗?
不高——但这个答案有个前提,而且这个前提在很多人那里是默认不成立的。
"上线之后服务器会很贵"这个判断,隐含着一个假设:用户的每个请求都要在服务端算一遍。上传文件、处理、返回结果,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 首页还有一个 Discover Omni 板块,自我介绍是「用计算揭示世界的惊人真相」。
更说明问题的是它的态度。广告负责人 Alexander Utz 说过,页面速度对他们没有商量余地,整个增长都依赖 SEO,Core Web Vitals 直接影响排名。
注意这里的因果:他们优化页面速度,首要动机是排名而不是省钱。但结果是一样的——一个把每个字节都抠过的站,带宽和 CPU 开销必然低。成本控制在这里是性能优化的副产品。
顺带一句,页面能不能被正常抓取和索引,比省钱更要紧。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 里都是几行配置的事,漏掉纯属浪费。
把活搬到浏览器里,是最彻底的一刀
三种信号里前两种是优化,第三种是配置。真正改变成本结构的是另一个动作——把计算从服务端搬到客户端。
具体路径就是 WebAssembly:把编解码器、压缩算法、ffmpeg 这类现成的 C/C++ 库编译成 wasm,在浏览器里跑。服务器从此只做一件事——发文件。
这一刀砍下去之后,"服务器成本高不高"这个问题会失去对象:你的机器变成了静态文件服务器,账单里最大的一项是带宽,而带宽又可以被 CDN 缓存吃掉大半。
一个更实用的记账方式
与其每月看账单总额,不如看两个比值:每千次会话的服务器成本,以及每千次会话的收入。
terrific.tools 那边收入侧是每千次会话 6.89 美元,目标是 10 美元。成本侧如果能算出自己的数字,两个一比就知道这个模式成不成立——成本侧的比值只要远小于 6.89,这个站在账上就是健康的,规模涨上去也不会失控。
算不出这两个比值,说明你还没把流量和成本对应起来,这时候讨论"贵不贵"没有依据。
剩下的判断
成本不是不能高,是应该高得有理由。如果一个站每个请求都必须在服务端干活——要读别人的数据、要调用付费 API、要跨用户聚合——那成本就是业务的一部分,涨了说明业务在涨。
怕的是另一种:成本涨了,但用户量没涨,或者涨的成本没有换来任何新能力。出现这种情况时,先别急着升级套餐,去数一遍有多少请求本可以在浏览器里跑完。你的站里,这一刀还剩多少没砍?