看到“业余时间搞副业”这几个字我就知道你在走一条和我一模一样的老路。白天上班写代码晚上回家折腾自己的小项目最后一看账单一个月几十美元的云服务器在跑一个日活可能就几个人的站为了一个展示页租着四核八G这种“大马拉小车”的状态持续了小半年。后来我下决心把副业项目的整套基础设施重做了一遍核心思路就一条能用免费额度覆盖的绝不自掏腰包。这套免费云方案我用了大半年覆盖两个内容站、一个工具类API、一个图片托管服务月成本从原来的两百多块压到了几乎为零。今天不绕弯子直接把我现在的整个选型、配置、踩坑记录都拿出来给准备做副业或者已经在吃云账单亏的人参考。1. 副业的钱到底流进了哪些云服务的口袋1.1 我曾经为“安全感”交过的学费第一版副业项目上线时我的思路还停留在“做项目买服务器”的阶段。一台2核4G的ECS挂着一个Node.js后端一个MySQL数据库一个Nginx静态目录再加一个公网IP。看起来配置不高但杂七杂八加起来一个月稳定在两百元左右。账单拆开看才心疼云服务器是大头包年才划算但包年意味着一次掏大几千。数据盘快照占了额外存储费为了“防止误删”我设了每天自动快照一个月又多出十几块。更离谱的是那个项目的实际用户量少得可怜后台日志显示大部分请求来自我自己手机上的浏览器——等于我每天醒来先在云服务器上跑几圈。这里的核心误区不是“云服务贵”而是我拿做生产级项目的惯性思维来跑副业项目。正式产品要考虑峰值并发、数据高可用、异地容灾副业项目根本不需要。副业只需要验证需求、积累用户、稳定运行成本必须无限压低。1.2 副业场景下每个成本项该不该花后来我给自己定了一套判断标准每个费用项都在这个框架里过一遍这个服务有没有免费额度够用的替代品。有直接切换没有再评估是否真的需要。这个功能有没有必要用“常驻服务器”承载。能用静态文件、边缘函数、按量计费搞定就不要养一台24小时开机却没人访问的机器。这个成本项是否会随着用户量增长而自动恶化。比如固定月租的服务器用户量从0到1000都不变而按量付费的Serverless用户量上去才花更多钱。副业前期应该选后者用户少时几乎零成本。我把维护时间折算成钱了吗。买服务器不只是花钱还得花时间打补丁、防攻击、处理宕机。副业最稀缺的是下班后的精力每多花一小时在运维上就少一小时写业务。做完这轮评估我意识到副业该走的路线非常清晰静态优先、函数计算替代长驻进程、托管数据库替代自建数据库、对象存储替代云盘且全部压在免费额度内运行。2. 我最终落地的这套组合不花一分钱的基础设施架构2.1 整体选型原则没有运维才是最省成本的运维这套方案的核心哲学是“无服务器化”。不是赶时髦而是副业场景下最合理的取舍。云服务器把计算、存储、网络、运行时全部打包卖给你你付的是“独占一台机器的钱”结果机器大部分时间在睡觉。Serverless类和托管类服务则把粒度拆分到函数调用、存储请求、带宽消耗按实际用量计费免费额度往往对个人项目绰绰有余。经过反复对比和实测我目前跑得最稳的组合如下职责使用服务免费额度说明前端静态站点Vercel支持GitHub导入自动部署100GB带宽/月边缘API/定时任务Cloudflare Workers10万请求/天自带免费CDN数据库Supabase免费项目500MB数据库适合轻量业务对象存储/图片Cloudflare R210GB存储100万次/月读请求域名解析Cloudflare DNS完全免费且提供隐藏源站能力这个组合的核心优势是把运维彻底剥掉了。我不需要关心服务器负载、不需要熬通宵打安全补丁、不需要再为磁盘报警提心吊胆。代码推到GitHubVercel自动构建发布API逻辑写成一个Workerpush上去就生效。后来我把监控、告警这类“服务器时代养成的好习惯”也拆掉了更准确说是不需要了——平台宕机会自动恢复这比自己修复一台半夜挂掉的ECS靠谱得多。2.2 为什么这几家组合而不是“全家桶”市面上任何一个大厂都提供建站、函数、数据库、对象存储的全套服务我为什么偏要混搭一是防止被一家绑定。某家云厂商的对象存储确实给新用户免费额度但到期后的续费价格令人咋舌。我把静态站点放在Vercel、图片放在R2即便哪天某一家的政策变了迁移单个模块的成本远低于换整套平台。二是各家最擅长的领域不一样。前端托管方面Vercel对Git工作流和预览部署的支持几乎无对手边缘计算方面Cloudflare Workers的冷启动速度和覆盖面优于多数云厂商的Fn产品数据库方面Supabase对PostgreSQL原生支持和实时订阅能力比自己用Node连MySQL省心太多。三是联盟关系减少路线风险。Cloudflare R2的上行流量免费绑定自己的域名后还能直接拉取Workers的数据等于把“对象存储API网关CDN”串成一条链路。这三家在ISSUE和官方文档里常常互为推荐关系生态兼容性实测下来很稳。3. 各环节的免费替代方案从搭建到上线的完整实操3.1 静态站点从零到上线Vercel的自动化功力足够深我接手过的副业项目里大约六成只需要一个展示页、一个小工具页面、或者一个面向搜索引擎的内容站。这类需求完全不需要后端渲染纯静态就够用。Vercel把这条路走成了康庄大道。具体流程不复杂我第一次用十几分钟全跑通把前端代码放到GitHub仓库建议用Next.js或Vite构建两种框架Vercel都能零配置识别。在Vercel官网用GitHub账号登录点“Add New Project”选择刚才的仓库。保持默认的构建配置框架会自己识别点Deploy等待一两分钟。部署成功后得到一个项目名.vercel.app域名这里只能作为临时的预览入口真正上线前还要做第5步。绑定自己的域名并在DNS处增加一条CNAME记录指向cname.vercel-dns.com。这一步之后每次git push代码Vercel会自动构建并灰度发布回滚也只要点一下。我试过在好几个平台上做静态托管Netlify的体验足够好但Vercel对Next.js的优化更深入如果你的前端基于React生态闭眼选Vercel。提示Vercel的免费版额度是100GB带宽每月对个人内容站来说这个数字比云服务器还耐扛。部署区域可调的选项目前只能在美国或欧洲如果你的用户主要在国内访问速度会比海外用户慢一些——这点在章节4.3里我会单独说。3.2 后端API和定时任务Cloudflare Workers的免费额度令人放心副业项目难免要有几个后端逻辑比如表单提交、文章阅读量统计、定时抓取数据。早期我为了这些逻辑单独租服务器属于纯粹的“杀鸡用牛刀”而且Nginx配置和进程守护还得花时间维护。Cloudflare Workers把这个问题彻底解决了。它本质是一个运行在云端边缘节点的JavaScript运行时你写的函数会被分发到全球节点用户从哪个地区访问就从哪个节点执行天然省略了“接入层路由到源站”这步延迟。一个最简单的计数器API只需要这样export default { async fetch(request, env) { const key visitor_count; const counter await env.COUNTER.get(key); const now (parseInt(counter) || 0) 1; await env.COUNTER.put(key, now); return new Response(访问次数: ${now}, { headers: { content-type: text/plain } }); } };把代码粘贴到Workers控制台点击Deploy马上获得一个公网地址。没有域名、没有服务器、没有运行时依赖这些传统部署步骤统统消失。免费版的额度是每天10万次请求个人项目使劲造也通常用不完。定时任务同样用Workers的Cron Triggers功能配置。比如我这个内容站每天凌晨要检查一次外部数据源是否更新只需要在控制台添加一个0 2 * * *格式的cron表达式平台到时自动调用该Workerexport default { async scheduled(event, env, ctx) { await checkExternalSources(); ctx.waitUntil(logResult()); } };3.3 数据落到哪里Supabase给了我一个敢用的免费PostgreSQL副业一旦涉及用户注册、内容管理、留言评论数据库就躲不掉了。最开始我想过用SQLite加文件存储后来发现并发一上去锁冲突会让人想砸电脑也考虑过自建MySQL但一想到还要保证数据不丢就头大。Supabase是目前我用过最省心的免费数据库方案。它本质上是一套托管的PostgreSQL自带RESTful API和实时订阅等于数据库和“后端接口”一步到位。免费版给了500MB数据库空间个人项目存到几千条文章记录完全没压力。连接方式很直接用官方Postgres驱动就能走标准连接-- Supabase控制台的SQL Editor里执行 CREATE TABLE posts ( id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, title TEXT NOT NULL, slug TEXT UNIQUE NOT NULL, content TEXT, created_at TIMESTAMPTZ DEFAULT now() );业务代码里按PostgreSQL的方式连接即可不用额外适配import psycopg2 conn psycopg2.connect( hostdb.example.supabase.co, port5432, databasepostgres, userpostgres, passwordyour-password ) cur conn.cursor() cur.execute(SELECT title, created_at FROM posts ORDER BY created_at DESC LIMIT 10) rows cur.fetchall()如果你更习惯MySQL同类选择里PlanetScale、Neon也有不错的免费额度但都比不上Supabase把“数据库API实时能力”打包得这么适合个人项目。实时订阅这个功能尤其值得说副业项目的后台管理界面、订单通知、协作编辑用订阅机制可以省掉一大半轮询代码。3.4 图片和附件存哪里Cloudflare R2的零流量费是真香副业项目一旦有用户上传图片存储和流量就是潜在成本黑洞。传统对象存储虽然单价看起来低但下行流量费一旦起来一张图被刷个几千次账单立刻变得难看。Cloudflare R2的价格结构很特殊存储费用和其他对象存储接近但下行流量完全不收费也就是出口流量0元。加上R2兼容S3 API代码迁移成本极低。我给工具类项目接R2时用的就是标准AWS SDK只是把endpoint换成R2的地址import { S3Client, PutObjectCommand } from aws-sdk/client-s3; const r2 new S3Client({ region: auto, endpoint: https://${ACCOUNT_ID}.r2.cloudflarestorage.com, credentials: { accessKeyId: R2_ACCESS_KEY_ID, secretAccessKey: R2_SECRET_ACCESS_KEY, }, }); await r2.send(new PutObjectCommand({ Bucket: my-avatar, Key: user-123.png, Body: imageBuffer, ContentType: image/png, }));免费额度是10GB存储、100万次读请求/月。10GB听起来不大但普通博客站一年也未必用得完如果真的某个月图片量暴增那也是收入增长带来的好烦恼而流量费用不用心疼。唯一的注意点是R2读请求按次数计费如果某个链接被高频热刷导致超额度5美元/1000万次的价格也远低于传统流量费。3.5 域名和DNS用最低成本维护体面入口域名很难找到在“免费额度”内长期可用的方案但好在域名本身已经足够便宜。.xyz、.top这类域名常年有首年几块钱的促销一个副业项目能用一两年。真正花钱的大头其实是解析和流量入口这里Cloudflare DNS提供了完全免费的解析服务顺手还能打开CDN、防DDoS。我在多个项目上采用的做法是把域名的NS记录指向Cloudflare然后所有子域名交给Cloudflare管理。这样Vercel站点用www子域、Worker API用api子域、图片服务用cdn子域全部在同一个面板里管理不需要再去域名注册商那边反复改记录。配置好后www.example.xyz→ CNAME到Vercel站点api.example.xyz→ 通过Cloudflare的Route将请求转发给Workerscdn.example.xyz→ 绑定到R2的公共访问域名或自定义域名这套组合把“域名管理”这个副业里最容易被忽视的环节彻底集中化忘记续费导致服务中断这种低级事故也能通过Cloudflare提醒避免。4. 免费方案的真实边界我踩过的坑和翻车现场4.1 免费额度也有“死亡陷阱”隐形扣费比没有免费更可怕免费额度最坑的不是“不够用”而是超量后自动转成付费计费。我曾在一个项目上开着自动备份某天凌晨数据库负载飙高瞬间触发了额外备份月底看到账单时一口老血。现在我在所有云服务控制台里做的第一件事永远是关闭自动扩容或者设置消费上限。R2和Workers这类服务默认超量后会直接进入付费档位不会停下等你处理。个人项目不具备收入流时强烈建议每天花几十秒看一眼控制台的用量仪表盘。给自己的API加一层请求计数和熔断逻辑别让某个爬虫脚本耗尽全天额度。有条件就开通邮件通知几乎所有服务都支持用量预警别嫌烦关键时刻能救命。4.2 Serverless的冷启动真的会带来可见延迟Cloudflare Workers的冷启动通常只有几毫秒但Vercel的Serverless Function在长时间无请求后冷启动可能要额外增加一两秒。这对低流量的副业站点尤其明显用户第一次打开一个页面脚本状态要等函数准备好才开始执行。我踩过一次很尴尬的坑给一个内容站的搜索接口加了个分词库本地跑得好好的部署到Serverless后首次访问耗时超过3秒而该函数只有二十个并发。排查半天发现是冷启动加载分词字典耗时太长。这类问题的解法也不复杂不用担心的热点接口保持活跃可以用Cloudflare的Cron Trigger每5分钟自己调一次函数“预热”但别指望免费额度之外的额外保障。数据量不大时尽量用静态生成来替代实时渲染页面直接构建成HTML推到CDN省掉函数执行环节。冷启动时间能不能缩短取决于运行时大小和依赖是否精简同样功能的Python比Node慢不少。副业项目优先用Node或Go写边缘函数冷启动体感好一个量级。4.3 地域差异是免费方案最大的隐性代价免费服务的数据中心通常部署在欧美区域没有你服务器的“就近部署”选项。我的用户有一半在海外用起来毫无违和感但纯国内用户访问Vercel部署的静态站首屏加载经常要2-3秒。R2自定义域名的访问经过Cloudflare CDN后效果稍好但遇到晚高峰仍可能有波动。副业项目在选免费方案前先想清楚用户画像。如果目标用户集中在国内完全用免费国际服务会直接影响留存。这种情况下我建议的过渡策略是先用“Vercel静态站国内静态托管服务”双线部署通过DNS分线路解析给国内外用户不同入口。等自然增长验证了需求、有了零星收入再考虑国内服务商的按量付费套餐不要一开始就上包年包月服务器。4.4 平台政策变动需要经常留意免费方案依赖提供商这是没有办法的事情。有些平台调整免费额度时不会提前通知超量突然停止服务或者扣费的前车之鉴不少。我的态度是“免费额度是赠品不是承诺”重要数据绝不只存在免费层。对策是数据三重冗余R2存储主副本、Supabase数据库存业务数据、每个周末再把关键内容导出到本地仓库一份。这套备份流程用GitHub Actions就能跑约等于零成本。5. 什么时候该从“免费方案”转向“正经付费”免费方案能扛住副业项目从零到一但它不是一种终点站而是一个过渡策略。当项目进入第二阶段必须主动判断什么时候付费。一个非常实际的判断标准是当“免费额度不够用”成为你用户增长瓶颈时再付费。这句话有三层意思第一个月有几百个用户免费额度绰绰有余付费就是浪费。免费额度不足但用户量在涨说明产品有真实需求付费升级是对增长的响应。付费应当精准投放在瓶颈环节而不是整体换大套餐。比如R2存储超了单独扩充存储Workers请求超了单独升级Workers不要因为一个环节满了就无脑上全套企业版。还有一类场景值得直接付费项目开始产生收入哪怕每天只有几块钱。为了这几块钱停机不值当一个月二十美元的支出如果能换来稳定的服务可以接受。我个人的玩法是开了一个“收入隔离账户”副业收入先进这个账户只允许用它支付云支出赚多了再考虑买点更省事的高级功能。提示付费升级之前先确认“免费额度不足”是否源于某个无意义的行为。我一度以为数据库要爆了查完才发现是某个采集脚本每月重复插入了几万条测试数据清理加限制之后又撑了半年一分钱没花。6. 我的迁移落地步骤五分钟切换一套方案数据无损还没下手的人可能觉得这套迁移很复杂其实网络上的开源工具和环境让切换变得非常轻量。我总结了一套可以照抄的落地顺序复制静态站把vercel.json或框架的构建配置录进新建项目Vercel部署后申请一个临时预览域名检查页面是否正常。导入数据库Supabase控制台支持从SQL文件导入如果你原本用MySQL可先用工具把表结构转成PostgreSQL兼容格式再批量插入。改写后端函数把原先Controller里的业务逻辑改造成纯函数形式放进Workers或Vercel的API Routes。这一步是工作量最大的但如果你原本就用Node或Python写业务改造量远小于重写。迁移文件存储写个脚本用S3 SDK把旧对象存储里的文件遍历复制到R2注意保留目录结构和Content-Type。切DNS所有验证无误后把域名记录切到新服务等待全球解析生效。DNS切换后观察一两天确认没问题再关闭旧服务器。迁移过程中最容易出问题的是“同时更新多份配置”导致的临时混乱。我给自己的建议是一次只换一个环节切换完成后验证、备份再动下一个。那些把切换当天搞成事故现场的项目几乎都是因为太心急域名、DNS、数据库全在同一分钟改掉出了问题根本定位不了。7. 免费云方案之外更该省的是副业者的精力整套优化下来月账单从两百多变成了一块七——一块七还是因为我懒得续费某个提醒服务。但是坦白讲比省钱更关键的变化是省心。以前每次周报数据的获取都要爬上服务器看现在所有服务都在面板里所有部署都是Push触发半夜服务器被扫描的焦虑感完全消失了。省下来的这些精力才是副业者最稀缺的资源。我把原来刷防火墙日志、处理DDoS告警的时间全投入到了写内容和观察用户反馈上项目迭代速度明显变快。免费云方案的意义远不止“不花钱”它让一个业余时间做项目的人把心思放回业务本身。如果你也正在为副业的云账单发愁先别急着劝自己“项目还没收入所以不该花”其实这整套方案花上半天时间就能迁移完。趁着周末精力好的时候按我给的顺序把五个模块拆开逐个替换下一个账单日你会发现原来副业真的可以轻装上路。