1.3 费用与免费额度：一年花多少

选型的最后一步是钱。1.2 节的对比表里我把成本判给了托管平台，但那个“托管便宜”是有前提的：小流量、善用免费额度、不做傻操作。本节把前提拆开，用我们项目上线第一年的真实账单建一个成本模型，你看完应该能估出自己的站一年要花多少。

先声明：所有数字是 2025 年我们项目的实际账单口径，各地域、各活动期价格会有出入。新用户在腾讯云网站托管活动页通常能拿到比列表价低不少的套餐，下文按列表价做最坏估计，心里有底再下单。

为什么静态站的天花板这么低？因为它没有计算。一个动态站要付数据库、应用服务器、负载均衡的钱，每一项都在“就算没人访问也得付”的范畴；静态站的全部成本几乎只随真实访问量浮动，没人来就几乎不花钱。这是选型阶段算不过来、但上云之后非常保值的一个属性。

换个说法总结这个规律：托管成本随流量而变，自建成本随时间而订。前者在你没流量时近乎免费，在爆发时贵得有道理（每一分钱都对应真实的服务增长）；后者无论有没有人访问都在固定消耗，而你需要自己决定要不要升配。两种模式的现金流心理完全不同，小团队更适合前者。

1.3.1 托管费用的三块组成

静态站托管在云上的费用拆到底只有三块：

第一年合计大约 300~500 元，平均每个月一杯咖啡。对应的自建服务器方案，一台最便宜的轻量机一年也要三四百起步，还不管 HTTPS 与防护的隐性人力。这就是 1.2 节成本一栏判给托管的原因——但要把价格压到这个水平，需要会花。

拆细一点年度账单的走势：前三个月几乎只有套餐费，因为没人访问；第四个月开始有自然流量，CDN 费用开始出现但只有几块钱；真正让账单跳动的两次，一次是产品被某社区推荐带来一波流量峰值（当月流量费多了四十多元），一次是上传了一批未压缩的产品图（存储和流量一起涨）。两次都没超出一百元，但都指向同一个工程动作：产物体积管控。这也是为什么我把控成本写进了团队的开发规范，而不是只当成财务的事。

1.3.2 免费额度在哪里，怎么吃满

云厂商对静态站这类场景给了不少免费额度，关键是知道边界在哪：

我们吃过一次亏：早期调试时把整个 node_modules 传进了存储桶，某天查账发现存储量异常。检查发现是部署脚本没排除依赖目录，白白占了几百 MB 存储。省钱的第一步永远是“少传废文件”，这属于工程习惯，不是商务技巧。还有一个动作值得养成：每个月花五分钟扫一眼账单明细，云费用没有“设好就不用管”这回事，小额异常拖半年就成了一笔说不清的糊涂账。还有一个动作值得养成：每个月花五分钟扫一眼账单明细，云费用没有“设好就不用管”这回事，小额异常拖半年就成了一笔说不清的糊涂账。

1.3.3 成本模型：流量决定总价

套餐费是固定的，变量是流量。把第一年的日均 PV 与账单拉出来做回归，你会发现 CDN 流量费基本随 PV 线性增长：

日 PV ≈ 2 万，平均每 PV 0.3 MB（图压过）
日均流量 ≈ 6 GB，月均 ≈ 180 GB
CDN 按量计费，月流量费约 12~20 元

关键可控变量是平均每 PV 的体积。同一个站，图片没压缩时每 PV 1.2 MB，压缩加 WebP 后降到 0.3 MB——一个动作把流量费砍掉四分之三。这就是为什么第二篇要单开一节 2.4 图片处理：图片处理既是体验工程，也是成本工程，这一年能帮你省的钱够再买一年套餐。

再补一个容易被忽略的杠杆：缓存命中率。CDN 命中与回源的价格差很明显，把静态资源的缓存时间从一小时拉到一天，回源请求能少掉一大半。我们做过一次对比，把 index.html 保持短缓存保证及时更新、把带 hash 的 js/css 设成长缓存，当月 CDN 回源量直接降了四成。这套分层缓存策略的完整配置在 4.1 CDN 接入，本节只说结论：缓存策略是免费的降价手段，写对了比谈商务折扣管用。

1.3.4 一个容易被忽略的账单：HTTPS 与请求次数

大部分人盯着流量费，忘了请求次数和回源。有几个真实场景会让账单跳一跳：

第一，页面里放了成百张小图（比如设计作品集站），请求数本身就会产生费用，sprite 或者合并非必要字体的优化在这种站上能省钱。

第二，CDN 节点分布对单价有影响：海外的请求往往比国内贵，出海站要把“用户在哪”算进成本模型。我们有个面向海外用户的活动页，把海外节点费用单列后才发现，占总流量三成的海外请求贡献了六成的流量费。

第三，缓存没命中导致的回源。CDN 缓存过期时间设得太短，用户每次访问都回源取，既慢又贵。第五篇会讲验证 URL 的缓存是否真的命中。

第四，被刷流量。静态站被恶意刷是最让人肉疼的，防护手段是提前在平台侧开启访问控制、设置带宽上限告警，而不是事后看着账单心痛。具体的监控告警配置在 5.2 监控告警，这里的教训是成本告警和可用性告警一样重要，第一天就该配上。

1.3.5 一年总账单：三种典型画像

按我们接触过的项目，静态站上云一年花费大致分三档：

第二个画像就是本书的场景。你会发现，对绝大多数刚起步的静态产品，托管路线的成本完全在“可以不犹豫”的区间；真正费钱的是流量起来之后，而那时产品通常已经赚钱了——先跑起来，再优化成本，顺序别反。

多说一句与定价无关的经验：永远用同一个账号体系对接商务入口。 小团队最容易在费用上出的乱子不是预算超了，而是账单散落在多个账号、多个项目里，月底谁也对不上。我们吃过这个亏之后定下规矩：所有云资源集中在团队账号，按环境打标签（prod、test、campaign），账单导出后按标签分摊，财务与工程看到的是同一份口径。

1.3.6 控成本的工程清单

把上面零碎的经验收成团队内执行的三条：

• 产物上线前过一遍体积：构建报告里超过 200 KB 的资源要解释来源，插件清单在 2.2 构建脚本 里。
• 部署脚本永远排除 node_modules、dist 之外的中间产物，传输前打印文件个数与总大小。
• 预算告警第一天就设：日费用超过阈值就通知，而不是月底看账单数心跳。

1.3.7 一个真实的成本意外：活动页翻车

值得单独记一笔：上线第二年做了一个限时活动页，市场渠道推了一波。当天下午 PV 冲到平时十倍，CDN 流量费半天烧掉半个月预算。原因是活动页里塞了一张 8 MB 的未压缩主视觉图，而赞助内容要求当天必须上线，没人 review 体积。事后复盘做了三件事：所有图片上传前强制走压缩流水线（2.4 的方案）、预算告警阈值调到可以提前一天感知异常、大图同步做 WebP 与压缩兜底。整个事件花费的额外成本，跟我们事后投入的工程时间相比，其实还便宜——但心理阴影是永久的。这个故事的教训：成本失控的第一现场永远是工程细节，而不是商务协议。

小结

静态站托管的合理年花费在几百元量级，主要变量是流量与产物体积。免费额度要靠工程手段吃满：压图、控请求数、设缓存、配预算告警。选型、成本都清楚了，下一节 1.4 最小可用：先跑一个 Hello World 正式动手，三步把站挂到公网。

延伸阅读

• 5.4 成本复盘：这站一年到底花多少：第五篇的年度账单复盘，比本节的预估更细。
• Node.js 网站托管实战：本书目录，费用相关的实操分散在各章。