用免费额度，把第一个产品跑起来

做产品最消耗人的阶段，不是写代码，而是「要不要先买台服务器」。

云厂商的免费额度，本质上是在替你做这个决定：先用起来，等到真的有人用了，再谈钱。

一、先把成本拆开

一个典型的轻量产品，成本只有四块：

成本项	传统做法	边缘做法
计算	一台 VPS，按月付	Workers，按请求计
存储	对象存储 + 数据库	R2 + D1 / KV
分发	CDN 另配	边缘网络自带
运维	自己盯	平台托管

传统做法的隐形成本是「闲置」：没人访问的时候，服务器照样在烧钱。边缘做法的好处是把固定成本变成了变动成本，而变动成本在早期几乎为零。

二、免费额度到底能撑多久

以我自己的站点为例，一个 Astro 预渲染的静态站，加一个读取分析数据的 API：

• 页面由 Static Assets 直接分发，不计入 Workers 请求；
• 只有 /api/* 走 Worker，每天 10 万次免费；
• 面板数据缓存 5 分钟，一天最多几百次真实读取；
• 前端零框架运行时，首屏几乎不消耗计算。

换算下来，这个站点在免费额度里能撑住每天几万次访问。对一个刚起步的个人站点来说，这个上限远高于「有没有人来看」的问题。

这就是免费额度真正的价值：它把「上线」这件事的心理门槛，降到了接近于零。

三、组合，而不是堆砌

免费服务很多，但不需要都用上。我的原则是：能用静态解决的，不要用动态；能用缓存解决的，不要用数据库。

一个够用的组合大致是这样：

• 静态页面：Astro / 任意 SSG，构建产物直接丢给边缘。
• 动态接口：一个 Worker，只处理必须实时的部分。
• 缓存：优先 Cache API，真的需要跨请求状态再上 KV。
• 数据：结构化查询用 D1，文件用 R2。
• AI：需要推理时再开 Workers AI，按神经元计费。

每多引入一个服务，就多一个需要监控、需要理解边界的东西。免费额度的另一面是注意力成本。

四、几个容易踩的坑

第一，别把免费额度当无限额度。 每天 10 万次请求听起来很多，但一个没做缓存的轮询接口，几千个用户就能吃完。上线第一天就该有速率限制和缓存。

第二，注意冷启动与区域差异。 边缘计算不是魔法，首次请求仍有冷启动；不同地区的表现也会有差别。涉及中国访问时，域名与线路要提前规划。

第三，日志和可观测性要给预算。 免费额度通常不含长期日志。至少保留错误率和关键路径的计数，出问题时才有据可查。

第四，把「升级路径」写进架构。 免费层到付费层的切换，最好是改一个配置，而不是重写一遍代码。

五、先上线，再优化

我见过太多停在本地的好想法。它们不缺技术，缺的是一个真实的访问地址。

免费额度最大的意义，不是省钱，而是让你可以在还没有答案的时候先开始。第一个版本不需要完美，它只需要存在，然后被打开、被使用、被批评。

写到这里，我想起自己常挂在嘴边的一句话：先做出来，再讲清楚。

产品如此，站点也如此。