如果你的副业还没做到稳定月入过千就先别急着给云厂商交一个月几百块的服务器租金。我在业余时间做了两年多小项目踩过的最大坑不是技术而是钱项目还没上线套餐、存储、带宽就先把我教育了一轮。直到我把技术栈整体换到一套免费云方案上一个月运维成本基本归零几个副业项目照样在跑其中一个工具站的月请求量还过了百万级。这套方案不是什么黑科技就是一堆官方免费额度的服务拼在一起关键是怎么拼不踩坑。这篇文章想跟你聊聊我最后留下了哪些免费组件每个组件解决什么问题以及整套部署记录和避坑清单。适合刚起步做独立开发、正在做自媒体配套工具、或者接私活又不想替客户长期背服务器成本的朋友。1. 副业上云之前先想清楚成本这件事很多搞副业的朋友第一步就是打开某家云厂商的控制台买一台云服务器。看起来没啥问题但仔细一算这笔钱花得实在冤枉。1.1 副业项目最容易忽略的固定开销我自己最开始也干过这事。给一个小工具站配了一台 1核2G 的服务器一年优惠完大概五百多不算贵。但我后来看后台监控CPU 使用率常年趴在 0.1% 上下内存也就用了几百兆。相当于我花几百块钱租了一台机器天天在那空转唯一稳定产生的只有账单。副业项目的成本其实比很多人想的要细分得多。云服务器只是其中一项你还要算域名续费、对象存储、CDN流量、数据库、邮件推送、监控告警。这些东西单看都不贵但堆在一起再加上一年12个月都要付的复利效应就成了一个不小的固定开销。我见过有人为了一个日访问量几十次的落地页买了一台 4核8G 的高配机器一年两三千。问他为什么买这么高他说以后可能要跑大数据。这就是典型的成本前置——业务还没起来先把未来三年的钱交了。副业跟创业一样重要的不是一开始投入多少而是能不能熬过验证期。验证期最怕的就是收入还没有账单先来了成本倒挂。另一个容易被忽略的点是时间成本。自己买的服务器不是装好系统就能跑要配环境、要打安全补丁、要处理 SSH 爆破、要定期看磁盘有没有满。业余时间本来就不多把精力花在机房运维上纯属给自己加班。免费的云函数、托管数据库看起来不够自由但恰恰是这种不自由帮你把运维的活儿外包出去了。1.2 免费额度不是白嫖是先试错的理性选择有人听到免费两个字第一反应是肯定不稳定肯定有坑。我的看法正好相反。云厂商做免费额度的逻辑是让开发者先在这个平台上把项目跑起来等业务大了自然而然会升级付费。这本质是获客成本不是慈善。对副业者来说这是信息差带来的红利。你的项目还没到需要承诺 99.99% SLA 的阶段免费额度完全够用。我跑了一年多的工具站Cloudflare Workers 免费版每天给 10 万次请求我日常用量连它的十分之一都不到。Supabase 免费版给了 500MB 数据库空间我存了上万条业务记录也就用了百分之几。免费方案的稳定性其实比你想象中好。云函数、静态托管这些东西底层是大型基础设施面的不是一台物理机的故障而是整个集群的调度。我自己买服务器的时候还遇到过机房网络抖动导致站点挂了半天的破事但用免费云方案这一年多核心组件倒是一次没宕过。当然免费不等于可以乱来。每个免费额度都有自己的边界你不看配额、不设告警等用量被刷爆才发现那就不是省钱而是踩坑了。我现在的习惯是把每个免费额度都当成一笔预算来管理每个月看一次用量报表。这个习惯帮我避开了至少两次超额风险。2. 这套免费云方案是怎么搭的整个架构的思路很简单不买服务器把前端、接口、数据存储拆开分别丢到各自擅长的免费托管服务里。这样每个组件都能吃到对应的免费额度互不拖累。2.1 静态页面交给托管平台我真的不需要一台常开服务器副业项目里落地页、博客、文档站、工具站的前端页面绝大多数是纯静态资源把它部署到服务器上其实是浪费。GitHub Pages 是很多人的第一选择免费、稳定、支持自定义域名和自动 HTTPS配置一次之后 git push 就能发版。但我个人更推荐 Cloudflare Pages因为它的带宽不限量还自带全球 CDN 加速每次提交代码后也是自动构建。这里有个观念上的转变静态页面和动态接口分开前端就成了一个页面文件集合。托管平台负责帮你把它分发到离用户最近的地方你根本不需要关心 Nginx 配置、证书续期这些琐事。副业初期这个省心程度是实打实的收益。因为前端是纯静态的流量再大也不会把你人拖垮。就算某天突然来了波热点流量Pages 平台的弹性能力也远强于你买的那台小服务器。我自己的经验是工具站上线第一天就被一个论坛转了瞬时 UV 冲到几千托管平台依然稳如老狗换作我以前的单机服务器Nginx 多半已经 502 了。2.2 动态接口用云函数替你省下为1个接口养一台服务器的钱副业项目只要涉及表单、登录、数据处理就绕不开后端接口。我之前脑子一热为了一个小功能专门买了台服务器后来想想这个功能一天的请求量可能还不到一百次。用云函数其实才是这个场景的正确答案。以 Cloudflare Workers 为例免费版每天有 10 万次请求配额开发体验和写普通 JavaScript 几乎一样。你只需要写一个入口函数其余的事——并发、扩缩容、边缘分发——全都交给平台。下面是一个最简单的示例它在访问/api/hello时返回一段 JSONexport default { async fetch(request, env, ctx) { const url new URL(request.url); if (url.pathname /api/hello) { return new Response( JSON.stringify({ message: hello, time: new Date().toISOString() }), { headers: { Content-Type: application/json }, } ); } return new Response(Not Found, { status: 404 }); }, };部署方式也很简单装好命令工具后在项目目录下执行登录和发布就行npm install -g wrangler wrangler login wrangler init project-api wrangler deploy第一次跑通之后你会发现自己好像回到了写代码就好的纯粹状态。没有服务器要登录没有进程要守护没有防火墙要配。真正的开发体验是从这里开始的。2.3 数据库与对象存储免费层也能存真实业务数据动态接口跑起来之后必然要接数据层。这一层我目前的选型是三件套结构化数据用 Supabase轻量 KV 场景用 Workers KV文件和图片用对象存储。先说 Supabase。它免费版是一个 PostgreSQL 数据库大概给 500MB 存储空间。500MB 什么概念存普通的业务记录几万条都绰绰有余。表格、关系、索引、SQL 查询全都支持还有一套现成的身份验证能力。副业项目的数据量短时间根本摸不到这个上限。然后是对象存储。我选的是 Cloudflare R2免费额度是 10GB 存储加每月 100 万次读操作最吸引人的是它对出口流量免费——这意味着用户每次访问图片、附件不产生额外的流量费。要知道很多云厂商正是靠流量费赚钱的R2 去掉这块成本对副业项目来说是极大的友好。这里要提醒一句各家免费的额度政策会不定时调整我上面提到的数字只是当时的参考。做选型的时候一定要去对应产品官网看一眼最新的免费计划说明别拿着旧信息做决策。2.4 把服务串起来整套架构零服务器也能跑把这些服务串起来整个链路是这样的用户访问域名 → DNS 和 CDN 层解析 → 静态页面返回 HTML/JS/CSS → 前端调用 API 域名 → Worker 云函数处理后端逻辑 → 数据写入数据库或对象存储。你会发现整条链路上没有任何一台你自己租的服务器。所有组件都是托管服务全部自动扩缩容不需要你在半夜爬起来修机器。以前我用云服务器的时候出门都要随身带个终端生怕服务挂了没法处理。现在我可以一周不管它它照样稳定运行。为了让这套架构更透明我还会加一个免费的第三方监控服务定时探测关键接口。一旦页面打不开或者接口超时我的邮箱和手机就会收到通知。这个监控本身也有免费额度对副业项目来说完全够用。整个架构跑通后我的体感是省心程度比我自己折腾服务器高了不止一个档次。3. 一次完整的部署实操记录从0到线上光说理论容易飘我拿一个实际项目来走一遍完整流程。这个项目叫轻预约是我给一个小型线下工作坊做的在线预约登记工具后来觉得通用性不错就一直维护着。它的结构不复杂但涵盖了静态页面、接口、数据库、域名绑定这几个副业项目的核心链路。3.1 一个真实副业项目预约登记工具需求拆开其实就三件事访客在页面上填写预约信息提交后存入数据库管理端能看到预约列表所有操作通过一个可读的子域名访问。技术选型如下组件选型免费额度参考用途前端页面Cloudflare Pages不限带宽展示预约表单和说明后端接口Cloudflare Workers每天 10 万次请求处理提交、查询预约数据库Supabase500MB 存储存储预约记录对象存储Cloudflare R210GB 存储、100 万次读操作存放用户上传的补充材料域名与DNS常规注册 Cloudflare DNS域名约每年几十元提供统一入口可用性监控UptimeRobot每 5 分钟一次的免费监控探测页面和接口存活为什么拿它举例因为这个项目规模不大但麻雀虽小五脏俱全几乎覆盖了副业常用到的所有免费云组件。你把它替换成自己的博客、工具站、小程序后端流程都是一样的。3.2 从前端到接口再到数据库三天部署完成第一步先部署前端。我把页面源码推到 GitHub 仓库然后在 Cloudflare Pages 控制台选择从 Git 导入选好分支之后它就自动开始构建。我的页面没有用重型框架就是纯 HTML 加一个表单构建命令都可以不填。几分钟后它给了一个默认的 pages.dev 域名我访问一眼页面基本正常。第二步把提交接口做出来。我新建了一个 Worker 项目接收 POST /api/booking先做基本参数校验再把预约数据写入 Supabase。关键信息都放在环境变量里不写死在代码中。代码部署用wrangler deploy几秒就完成控制台直接给了一个 workers.dev 域名。我顺手配了路由规则api.mydomain.com/api/*指向这个 Worker这样对外入口就是一个很干净的子域名。第三步初始化数据库。我在 Supabase 控制台执行了一条建表语句把预约需要存的字段都定义好create table bookings ( id bigint generated by default as identity primary key, name text not null, contact text not null, slot timestamp not null, note text, created_at timestamptz default now() );设置完 Supabase Connection String我在 Worker 里用环境变量读取它。这样本地开发和生产环境可以用不同的配置代码本身不需要改。第四步绑定域名并验证。我在 DNS 管理里给mydomain.com加了 CNAME 记录让www指向 Pages 域名让api指向 Worker 路由。等 DNS 全球生效后我打开https://www.mydomain.com和https://api.mydomain.com/api/health分别确认页面和接口都正常返回。到这里整套服务已经跑在免费云方案上了。实际操作下来真正花在写业务逻辑上的时间不超过一天剩下的时间全在配域名、等 DNS、核对环境变量。可能是我踩过太多次坑之后的经验但这套流程确实做到了零服务器、零成本启动。3.3 算一笔账原方案和免费方案一年差多少这套方案一年下来花了多少钱我特意翻了一下账目除了域名一年约 70 元之外其余全部是零。对比我最早的那种做法一年省下的费用相当可观费用项旧方案自购云服务器免费云方案云服务器约 500-1000 元/年0 元域名约 70 元/年约 70 元/年对象存储和流量按量计费预估 100-300 元/年0 元数据库包含在服务器或额外购买0 元监控告警约 50-100 元/年0 元合计约 720-1470 元/年约 70 元/年流量越大这个差距越夸张。因为我用 R2 做存储出口流量不收费以前那种被用户下载附件导致流量账单飙升的焦虑彻底消失了。用量监控方面我会每两周看一次三个核心指标Workers 的请求数、Supabase 的存储用量、R2 的读写操作数。所有控制台都有现成的用量页面不需要自己搭 Prometheus。正常业务量下我连额度的零头都用不到。当然还是要以官网最新的免费计划为准毕竟额度政策是动态的半年一次地刷新认知非常重要。4. 免费云方案常见问题与排查技巧免费方案用久了总会碰到一些不大不小的问题。下面这些坑基本覆盖了我这一年多遇到的大部分故障场景。4.1 我踩过的几个典型问题直接照着查现象可能原因排查方法接口返回 404Worker 路由没绑定到域名路径在控制台检查路由匹配规则确认api/*指向目标 Worker接口偶尔超时云函数冷启动或达到并发限制看在线请求数曲线确认是否触顶免费配额超时体验可用前端重试缓解数据库连接失败连接串被盗用、IP 白名单限制、连接数打满检查连接串和环境变量确认 Secret 是否泄漏把连接池调小页面样式丢失静态资源路径写成绝对地址改用相对路径或基于部署根路径生成 URL域名无法访问DNS 缓存、CNAME 未生效、SSL 证书未签发用 dig 工具查解析记录确认记录类型指向正确证书一般会自动签等待几分钟免费额度被刷爆被爬虫或恶意请求大量调用开用量告警给关键接口加简单的速率限制或人工验证我最常被问的是接口偶尔超时这个问题。其实大部分时候不是接口真的挂了而是首次冷启动或者边缘节点在做路由预热。对副业项目来说这个超时时间用户基本感知不到但如果你想进一步优化可以给接口加一个缓存层把重复查询直接命中边缘缓存连请求都不用打到数据库。4.2 免费方案也要有安全意识和备份计划免费不等于可以裸奔。恰恰因为很多服务的配置入口简单人反而容易放松警惕。我有一次不小心把数据库连接串直接写进了前端仓库结果被一个扫描脚本扫到被人白嫖了几天存储好在没有造成实质损失。从那以后我把所有密钥统一放进了环境变量并且规定代码仓库里永远不允许出现真实的连接串、Token、密钥。接口层面我还加了 CORS 限制和请求来源校验。Cloudflare Workers 里可以很方便地判断 Origin 头如果来源域名不在我的白名单里直接返回拒绝。这一步能挡住绝大多数顺手牵羊的跨域调用。备份这件事我以前觉得自己写个脚本导出 SQL 太麻烦结果真遇到一次数据库误删数据整个人都懵了。现在的习惯是每周自动从 Supabase 导出一份 SQL 备份放进 R2 的私有桶里保存。整个过程用 Worker 定时触发一个月跑下来也没消耗几个免费额度。副业项目数据量小但这个习惯能让你睡得踏实。4.3 免费方案不是终点什么时候该升级付费免费方案虽好但它不是终点而是一个帮你过渡到业务被验证阶段的手段。我给自己定了几条升级的判断标准当项目稳定产生收入且收入能覆盖升级成本时立刻升级当免费额度的使用率连续三个月超过 80%而且这不是刷出来的假流量时升级当用户开始对你说这个页面打开有点慢时也值得升级。升级的路径没有想象中可怕。因为我从一开始就把代码和环境变量分离了数据库也用的是标准的 PostgreSQL 接口所以从免费方案迁到付费方案基本就是新建一个更高配置的实例把连接串换掉再重新部署一次 Worker。代码不用改结构不用动只需要在控制台点几下按钮。这种随时能走的架构才是免费方案最大的自信来源。最后说一点我自己的体会。这套免费云方案真正帮我省下的其实不只是每个月几百块的账单。它让我在业余时间做项目时不再被又要花钱了这个念头反复拷问也让我敢丢下一个项目开始做下一个项目。免费的额度有限但它给到的是一个极低的试错门槛这正是副业起步阶段最需要的。如果你也打算搞副业我建议你先别急着花钱买服务器把需求拆开静态页面、接口、数据库分别交给对应的免费平台跑起来再谈升级。最后再分享一个小技巧所有用到的免费额度都可以设置用量告警提前订阅通知这一条能帮你避开九成的免费套餐翻车事故。