免费托管的天花板在哪

2026.10.30 No. 002 约 5 分钟

Cloudflare Pages 的免费额度限制的不是带宽，是构建次数和单文件体积。这两个数字决定了它能承载什么样的站，不能承载什么。

把一个静态站放上 Cloudflare Pages，免费档的额度是这些：

最显眼的那行是「带宽不限」。这确实是它比同类服务强的地方——Netlify 免费档每月 100 GB 流量，Vercel 免费档 100 GB，超了要么停站要么掏钱。Pages 的静态资源不限量，一个被刷爆的页面不会产生账单。

但真正会卡住人的不是带宽。是中间那三个数字。

500 次构建，一天 16 次

按月算 500 次，摊到每天是 16 次。听起来很多，实际上取决于你的工作方式。

如果你习惯「改一个字提交一次」，一天推 20 个 commit 很正常，那就超了。如果你攒着改完一起推，一天两三次，永远用不完。

更需要注意的是并发是 1。意味着第二个构建要排队等第一个跑完。一个 Astro 站点冷构建大概 30 秒到 2 分钟，排队本身不痛苦，痛苦的是你在等预览的时候不知道前面排了几个。

绕开的办法很简单：本地 npm run build 验证通过再推。预览部署不是用来当开发服务器的。

一个 Astro 站，每篇文章生成一个 HTML。1000 篇文章就是 1000 个文件，加上标签页、分页、静态资源，大概 1300 个。看起来离 20,000 很远。

但图片是按文件算的。如果你给每篇文章配两张截图，1000 篇就是 2000 个文件。三年下来，5000 篇文章加一万张图，就摸到上限了。

这个数字对个人博客是够的，对图片站是不够的。真到了那一步，解法是把图片挪到 R2（对象存储，免费 10 GB 存储 + 无限出站流量走 Cloudflare 网络），站点只留 HTML 和 CSS。

单个文件 25 MiB。一张 4K 截图大概 3–8 MB，压缩后 300 KB 到 1 MB，没问题。一个 3 分钟的手机视频，200 MB 起步，直接出局。

这条限制的实质是：Pages 不是文件托管服务。它假设你放的是网页和网页依赖的资源，不是媒体库。视频要么放 YouTube / Bilibili 外链，要么放 R2 再用 <video> 引。

我见过有人把 PDF 论文直接扔进 Pages 站点，一篇 30 MB，第一次部署就失败，报错信息还不太明确。这类需求应该用 R2 的公开桶，配一个自定义域，行为和 Pages 没区别。

如果站点需要一点后端逻辑——表单提交、API 代理、访问计数——Pages Functions 会把请求计入 Workers 的额度：

10 万请求对个人站很宽裕，一天 10 万 PV 的博客已经不小了。但 10 毫秒的 CPU 时间是个容易踩的坑。它不算网络等待时间，只算实际计算。听起来苛刻，实际上意味着：不能在里面做图片处理、不能跑正则密集的文本解析、不能做递归查询。

一个典型的反例是想在 Worker 里把上传的图片转成 WebP。图像编码动辄几百毫秒 CPU，必然超时。这种事得放客户端做，或者用 Cloudflare Images（收费）。

适合：静态博客、文档站、作品集、落地页、JAMstack 前端。构建频率不高，内容是文本和压缩过的图。

不适合：视频站、文件分享、图片库、需要长时间计算的服务、高频部署的团队协作项目。

判断方法很简单——问自己三个问题：

三个都是「否」，免费档能一直用下去，没有到期日，没有隐藏账单。有一个是「是」，就得换方案或者拆开——通常是把那一部分挪到 R2 或外部服务，主体还留在 Pages。

免费不代表零成本。真正的成本是迁移成本。

把站点绑死在某个平台的专有能力上（比如某个特定的边缘函数 API、某个私有存储接口），三年后想搬家就得重写。所以我在这个站上做的选择是：输出纯静态 HTML，图片走标准 <img>，没有任何平台专有 API。

代价是放弃了一些便利——没有边缘渲染、没有内置的表单处理。收益是 dist/ 目录扔到任何一台 nginx 上都能跑。

对一个可能活很多年的个人站来说，这个交换是划算的。