企业官网建设流程全解析

这些年因为做技术博客和一些小工具，我一直在找免费云服务。网上一搜确实一大把，什么永久免费虚拟主机、新用户免费试用一年、注册送几百块代金券，看着都挺诱人。可等我一个个试下来，真正能让我放心把东西放上去、过三个月再回来看还活着的，几乎没有——不是到期涨价，就是各种限速，要么干脆消失。直到后来我换了个思路，认真研究各家面向个人开发者的免费套餐，才总算找到一个真正稳定能用的，这一用就是大半年，博客、图片、接口全放在上面，几乎没操心过。

“这一个”是谁，我后面会花一整章讲清楚。但在说它之前，我特别想把找免费云服务这几年踩过的坑、总结出来的判断标准先列出来。因为很多人跟我一样，其实不是不会找，而是被各种“免费套路”坑怕了，一听到免费两个字就本能地怀疑。这篇就来聊聊我的完整经历，以及最终那个让我踏实的方案。

1. 找了三四年免费云服务，我把坑都踩了一遍

1.1 我的需求其实很简单：能长期跑，别天天折腾

作为一个搞技术的人，我要的其实不多。个人博客需要一个能稳定访问的托管空间；写文章要配图，需要一个能存图片的图床；平时写点小脚本、做点数据抓取，需要能暴露API接口的地方；偶尔还要跑个定时任务，比如每天往邮箱发一条提醒。这些需求都很轻量，但胜在数量多、持续时间长。

最关键的一点是，这些都是个人项目、学习项目，我实在不想为它们掏钱买服务器。所以我把目光瞄准了免费云服务。一开始我以为这事很容易，免费嘛，注册就能用。但实际用下来才发现，难的不是“申请”，而是“长期”。很多服务给你的额度就头几个月，到期之后不升级就停服；还有的服务表面上免费，等你把数据传上去才开始限速；更坑的是那种突然改规则、甚至整个业务直接下线的。

1.2 我踩过的免费资源类型，基本可以列一张避雷表

这些东西我真真实实都试过：

• 免费虚拟主机：界面上广告多得吓人，速度也慢，偶尔直接打不开。放点临时测试文件可以，放正经内容完全不行。
• 新用户免费试用券：注册送几十到几百块的代金券，看着很香，但用完之后要按原价续费。如果你是短期测试，那很划算；想长期白嫖，是不可能的。
• 公共图床：确实有些还能用得不错的，但公共图床最大的风险是图片内容不受控，域名一换，你历史文章里所有的图全部裂掉，想找回来都难。
• 免费域名：这个方向更不靠谱，很多免费域名的续期条款说变就变，数据绑定在上面，域名没了，服务也就断了。
• 各种“永久免费”的小厂服务：有的当时确实给了很高配置，但运营了不到两年就宣布停止服务，用户数据能不能导出都成问题。

这些坑走下来，我对免费云服务的态度从一开始的“来者不拒”，变成了“必须先确认这家的免费层能活过三年再说”。

1.3 我的需求清单，其实是在一次次踩坑后被逼出来的

踩坑次数多了，我给自己定了一份“长期免费云服务筛选清单”，每一条都是用实际操作教训换来的：

• 不能限期免费，得是那种注册进去就一直是免费层，不需要主动续期的；
• 不能要求绑定信用卡，对个人开发者来说，绑卡本身就是一种心里负担，老想着会不会哪天一觉醒来被扣费；
• 核心功能必须够用，不能是阉割到没法干活的程度；
• 服务商本身要有明确的商业模式，能让我相信它不会明天就跑路；
• 数据进出要方便，最好支持标准协议，万一以后真要迁走，不至于被锁死。

按这个清单去筛，市面上的免费方案瞬间淘汰了一大半。也正因为如此，当我遇到最终那个方案时，我能很确定地判断：就是它了。

2. 免费资源的两大宿敌：限制与跑路

2.1 时间型陷阱：试用期一结束，账单迎面而来

很多免费云服务，本质上不是“免费”，而是“限时免费”。最常见的套路就是新用户注册后，送你几个月甚至一年的免费额度，时间一到，如果你忘了主动取消或者停机，系统会默认按正常资费从你的支付账户扣钱。

这种设计本身并不是骗局，很多云厂商的条款里写得很清楚，只是用户注册时根本来不及细看。我身边就有朋友用了某大厂的免费试用服务器，到期忘了续费确认，结果第二个月直接从账户里划走一百多。更麻烦的是，跨区域访问、快照、公网IP等附加资源往往是独立计费的，你以为自己在用免费资源，其实账单已经悄悄累积了。

所以我对“免费云服务”的定义在踩坑后变得很严格：必须是没有时间限制的免费层，而不是新用户专享的体验套餐。时间限制这个东西，会让人在使用过程中一直处于倒计时状态的焦虑里，特别消耗精力。

2.2 额度型限制：有些不算不给用，而是让你很难受

除了时间限制，很多免费服务会在额度上做文章。比如免费CDN，写着流量不限，但节点数量少、回源带宽窄，高峰期打开网页要转圈五秒；免费存储空间，写着10GB，但上传速度不到100KB/s，传个大文件能等到天荒地老。

这些限制往往不会写在首页宣传语里，得你真正用起来才感受得到。而且免费额度通常不是一个总数那么简单，它覆盖了存储、流量、请求次数、API调用频率、并发连接数等好几个维度。任何一个维度触顶，服务都可能被暂停或者降级。说实话，对个人项目来说，稍微有些限制可以理解，但如果限制多到影响正常使用，那这个“免费”就没什么实际意义了。

2.3 跑路和变卦：很多“永久免费”撑不过两年

前面两类坑，多少还能在条款里看到一点痕迹。真正的杀手是“跑路”。我记得有一个国外的小主机商，当年推出了永久免费套餐，我兴致勃勃地注册把博客迁了上去。结果不到一年半，官网直接无法访问，数据也没导出，好在我的博客源文件还在本地，只是重新找地方部署了一次。

变卦的情况更多。有些服务商初期为了拉用户，免费额度给得非常大方，等用户养成了依赖，再悄悄调整规则：免费用户降级、请求数大幅缩水、新增各种限制。这种事在各行各业都见过，免费服务尤其常见。原因也简单，免费服务本身不赚钱，如果服务商没有足够强大的商业业务来补贴，那它迟早要从免费用户身上找收益，或者干脆放弃这个业务。

经历了这些之后，我得出一个结论：判断一个免费云服务能不能长期用，首先要判断这家公司靠什么赚钱。只有那种把免费当作获客入口、靠付费套餐盈利的大体量公司，它的免费层才可能稳定存在很多年。

3. 各大厂商的免费方案，我逐个试过的真实体感

3.1 国内云厂商：羊毛好薅，但长期依托要精打细算

阿里云、腾讯云这两家，我相信只要折腾过服务器的人都不陌生。它们对新用户的免费试用政策相当大方，动不动就是几个月的免费云服务器、免费的对象存储额度。如果你是第一次用，薅一波新人福利是很划算的，用来学习Linux、搭个小项目绰绰有余。

问题在于，这些免费资源的定位是“拉新尝鲜”，而不是“陪你长期成长”。新人试用期过了之后，续费价格就是正常商用价格。对一个只想免费跑个人项目的用户来说，这个成本是没法长期承担的。当然，它们也有一些长期免费的基础功能，比如免费的SSL证书、云监控基础版，这些确实是良心，但作为主力计算资源是不现实的。

另外，国内云厂商的免费资源通常需要实名认证，这个流程本身没有问题，只是对追求“开箱即用”的开发者来说，前期步骤会多一些。如果你本身就是国内用户、目标访客也在国内，那国内云厂商的免费资源是个值得考虑的选项，只是要接受“免费只是暂时的”这个现实。

3.2 全球开发者向的免费套餐：不少都要绑卡

海外几个头部云厂商，比如AWS和Google Cloud，它们都提供“Always Free”类型的永久免费层。AWS的免费层覆盖了不少服务，比如某些规格的云主机12个月免费、某些存储永久免额度；Google Cloud也有类似的结构。

但这类服务的体验门槛在于注册时需要绑定信用卡。不是说绑定银行卡本身有多可怕，而是对“只想找个免费地方把项目跑起来”的人来说，绑卡会增加一种心理负担：我得时刻关注用量，防止某个月流量超标，结果账单上多了一笔百元消费。而且这些平台的免费层条款相当复杂，涉及实例规格、区域、计费项等细节，稍不留神就会超出免费范围。实际上我身边认真研究这些条款的人并不多，大多数人都是绑定完卡，稀里糊涂用着，直到某天收到扣费通知才彻底清醒。

我并不是说这些平台不好，它们的免费层确实能打，只是不适合像我这样追求“省心”的用户。我更希望找到一种不需要绑定支付方式、注册即免费、规则清晰的服务。

3.3 小厂及个人分享的“免费资源”：看起来香，用起来慌

还有一类资源，是在各种博客、论坛里被反复分享的“小众免费服务”。比如某些签到送时长的机场、某些个人开发的免费API、某些注册就送的大容量网盘空间。这类服务在刚推出时往往很惊艳，配置高、期限长，让人误以为自己捡到了宝。

但用一段时间后你会发现问题：要么作者失去维护热情，要么项目因为成本压力宣布停止，要么服务条款出现大幅调整。倒不是说所有小厂服务都会这样，但整体风险确实比大厂高不少。我个人已经不太敢把重要数据放到这类平台上了，因为数据迁移的隐性成本远比表面上省下的几十块钱要大。

基于这些体验，我把最终的选择目标锁定在了一个有商业支撑、免费额度明确、注册不绑卡、业界口碑稳定的云服务商上。

4. 最终留下的这一个：免费用到什么程度才叫稳定

4.1 为什么是它：免费不是试用，商业模式撑得住

绕了这么大一个圈子，该说正主了。我最终留下来的，是Cloudflare。很多人只把它当成一个CDN服务商，最多用来给网站做下加速和防护。但如果你深挖它的免费套餐，会发现它对个人开发者来说，几乎是一个被低估的“免费云资源包”。

Cloudflare的商业模式很清晰：它为全球大量免费用户提供服务，然后用这个庞大的用户基础吸引企业客户购买付费套餐（Pro、Business、Enterprise等）。免费层在这里的角色是“获客入口”和“生态粘性”，而不是一个临时的促销活动。正因为如此，它的免费套餐没有“新用户专享”这种限制，注册进去就一直能用，也不会到期自动扣费。

这一点太重要了。我用了将近一年，从来没有收到过任何“试用到期”“请升级续费”的提醒，后台也不需要绑定支付方式。对一个免费云服务来说，能做到这个份上，安全感直接拉满。

4.2 免费套餐全景：从CDN到对象存储，几乎啥都有

Cloudflare免费套餐覆盖的场景比我预期的要广得多。这里列一份我常用的免费资源清单：

• CDN加速：绑定在Cloudflare上的域名，全球节点自动缓存静态资源，带宽流量不单独计费，个人站点的流量基本可以忽略不计。
• DNS解析：不限域名数量，解析速度和稳定性在免费DNS里属于第一梯队，还附带基础的DDoS防护。
• Pages静态托管：可以连接Git仓库，自动构建部署静态博客和前端项目。免费版提供无限的带宽和请求量，构建次数每月有500次额度，个人开发完全够用。
• Workers边缘函数：可以在全球边缘节点运行JavaScript代码，每天10万次免费请求。这意味着你可以不买服务器，就实现一个可用的API后端。
• R2对象存储：提供10GB免费存储，每月有免费的读操作和写操作次数，出站流量不收钱。用作个人图床和文件备份非常合适。
• Turnstile验证码：替代传统的reCAPTCHA，完全免费且不向访客弹出烦人的验证页面。
• Email Routing：可以将自定义域名的邮箱转发到你的任意真实邮箱，省去了折腾邮件服务器的麻烦。

这些服务单拎出任何一项，市面上都有对应的免费替代品，但把它们整合在同一个后台、统一管理、免费用到底的，目前我只在Cloudflare上体验到了。

4.3 免费额度的边界：哪些场景随便用，哪些场景要克制

任何免费层都有自己的边界，Cloudflare也不例外。我实际用下来，这几个地方要特别注意：

• Workers单请求CPU时间：免费层对单个请求的CPU执行时间卡得很严，一些复杂计算、大数据处理很容易超时。适合做轻量接口，不适合跑重型逻辑。
• Pages构建次数：每月500次构建，看起来很多，但如果你采用“每次提交都触发构建”的模式，遇到频繁改代码的阶段，次数会消耗得比想象中快。
• R2操作次数：虽然出站流量免费，但读和写的操作次数是按次计费的，免费额度大概每月百万次级别。对个人图床没问题，但如果你挂了一个高访问量的图片接口，操作次数可能会成为瓶颈。
• CDN缓存清理次数：免费版清理缓存的次数有限，频繁刷新静态资源缓存时容易触顶。

这些边界并没有影响我的使用，因为我的场景就是个人博客、小工具、少量API。但如果你想拿它做商业项目或者大流量应用，还是需要搞清楚额度明细，并做好升级付费的心理准备。

5. 从注册到落地：三个最能打的免费用法实操记录

5.1 第一步：没有信用卡也能注册

Cloudflare注册是我遇到过最省心的流程之一。打开官网，点注册，填邮箱和密码，进邮箱点验证链接，就完事了。全程不需要绑定任何支付方式，也没有手机验证码强制绑定。

注册完成后，后台首页会引导你添加站点。这里我要提醒一句：如果你只是打算用Workers或者R2这类开发者服务，不一定要先把域名迁过来。可以直接进入“Workers和Pages”板块操作。我当初就是先注册、先把服务跑起来，后来才慢慢把域名托管到它上面，整个过程完全按自己的节奏来。

对习惯了各种“注册即绑卡”流程的人，这种无支付方式的注册体验确实会让人好感度直线上升。不过也要说清楚，Cloudflare是一家运营全球业务的国际云服务商，注册和使用时的网络情况、页面加载速度，可能因本地运营商而有所不同，这一点用哪个国际服务都一个样。

5.2 静态博客上线：取代我原来的服务器托管

我博客之前放在一台国内云服务器上，后来为了省钱关掉了，改用Cloudflare Pages托管Hugo生成的静态站。步骤不复杂，但每一步都有要注意的细节：

第一步，把博客源码推到GitHub私有仓库。第二步，在Cloudflare后台进入Workers和Pages，点击“创建”，选择Pages标签页，点“连接到Git”，授权后选中你的仓库。第三步，配置构建参数。如果你是Hugo项目，构建命令填hugo --minify，输出目录填public，环境变量里加上HUGO_VERSION，比如0.128.0，这样能避免默认版本太旧导致构建失败。第四步，点保存并部署，系统会自动拉代码、构建、生成一个xxx.pages.dev的预览域名。

部署完成后，我给博客绑定了自定义域名。这一步的前提是你的域名已经托管在Cloudflare DNS上，操作时会非常顺滑：在Pages项目里找到自定义域，输入你的域名，后台会自动添加一条CNAME解析记录，几分钟后就可以通过自己的域名访问了。

我遇到过一次构建失败，原因是构建命令写错了，输出目录填成了public/多了一个斜杠，导致Pages没找到产物。看构建日志立刻就能发现，改过来重新部署就好。这个流程整体上比我之前自己配服务器、装Nginx、搞证书要省心得多。

5.3 零成本接口：一个日均可用的轻量API

如果说Pages解决了“网站托管”的需求，那Workers就直接解决了我“免费API”的需求。它的逻辑很简单：你在Cloudflare的边缘节点上部署一段JavaScript函数，每当有人访问你设定的路由，这个函数就会被执行并返回数据。

我写了一个简单的接口，用来返回当前时间：

export default { async fetch(request, env, ctx) { const data = { code: 0, message: 'ok', data: { time: new Date().toISOString() } }; return new Response(JSON.stringify(data), { headers: { 'Content-Type': 'application/json' } }); } }

在Workers页面创建项目、粘贴这段代码、点击部署，几秒钟后你就能得到一个xxx.workers.dev的域名，直接访问就能看到JSON返回。这个接口每天有10万次免费请求，个人项目根本用不完。

如果你有自定义域名，还可以在Worker的设置里添加“路由”，比如配置api.yourdomain.com/*指向这个Worker，这样你的接口就拥有了一个看起来非常专业的地址。整个过程不需要买服务器、不需要配Nginx、不需要管SSL证书，对只想快速暴露一个后端接口的场景来说，效率非常高。

5.4 图片存储与图床：R2的另一种打开方式

R2是Cloudflare推出的对象存储服务，兼容S3协议，最吸引人的是没有出站流量费。我把它用作个人博客的图床，第一感受是“图片加载速度比之前用的公共图床靠谱多了”。

配置步骤也不复杂。先在R2页面创建一个存储桶，比如叫blog-images。然后在R2的“管理API令牌”页面创建一个API令牌，权限选择“对象读”和“对象写”，这个令牌会给你一对Access Key ID和Secret Access Key。记下来，后面PicGo要用。

PicGo是一款常用的图床管理工具，支持S3插件。在PicGo里选择S3，填上Endpoint地址，格式是https://<ACCOUNT_ID>.r2.cloudflarestorage.com，Region填auto，再把刚才的Access Key和Secret填进去，就可以正常上传了。

上传成功后，如果你想直接在浏览器里访问图片，需要把存储桶设为公开访问。在R2存储桶的设置里找到“公开访问”选项，开启后会生成一个pub-xxxx.r2.dev的公开访问域名，图片上传后的链接就可以直接放进文章里了。

这里我踩过一个坑：刚配置完PicGo时，上传明明成功了，但打开图片链接却提示没有权限。后来才发现是因为存储桶的公开访问没有开启，只生成了API令牌并不代表存储桶是公开的，需要单独去设置里打开，两个操作要配合使用。另外，如果你的博客启用了防盗链，还要在R2的CORS设置里把允许的来源域名加上，否则部分平台里图片会显示不出来。

还要强调一句：API令牌的Secret一旦写入前端代码或者提交到公开仓库，就相当于把存储桶的操作权限交了出去。自己用的话，令牌放本机就好，存储桶也要尽量只给“对象读”权限，不要开放“对象写”，避免被恶意上传。

6. 用了大半年，我的结论与挑选逻辑

6.1 半年的真实使用感受

这段时间用下来，最大的感受是“它像个基础设施，而不是一个需要伺候的项目”。Pages的自动构建一直很稳定，我每次往GitHub推代码，几分钟后博客就刷新了；R2上的图片没有丢过一张，加载速度在个人网站上体验很不错；Workers接口也没有触发过任何限流，后台看用量，距离免费额度还有很远的距离。

要说最不满意的点，其实是Cloudflare后台改版频率有点高。有几次我凭旧记忆找某个功能入口，点了半天没找到，最后在帮助文档里重新确认了新位置。这是一个小烦恼，但可以忍受，毕竟服务本身的稳定性确实过关。

还有一点经验是，Pages构建偶尔会因为上游依赖更新而失败，比如某个插件变了版本。遇到这种情况别慌，去构建日志里看具体报错，通常很快就能定位。日志的信息量很大，一眼就能看出是哪一步出了问题。

6.2 什么情况下，别迷信免费层

虽然我说Cloudflare的免费层很能打，但我不建议大家无脑把所有项目都往上面放。如果你的业务有比较高的服务可用性要求，比如是商业客户的官网、交易类系统，那我建议还是选择有明确SLA保障的付费云服务。免费层没有SLA保障，出了问题只能靠社区和工单，时效性肯定没法跟付费比。

如果你的主要访客都在国内，对访问速度有极高要求，那Cloudflare的免费CDN节点可能不是最好的选择。国内云厂商的对象存储加CDN免费额度，在国内网络环境下的表现可能会更稳定。这个需要根据自己的目标用户群体来判断，没有绝对的好与坏，只有合适不合适。

另外，如果你需要长时间运行一个高CPU消耗的任务，Cloudflare的免费Worker并不适合。它的定位是边缘计算和轻量任务，强行跑重型计算，只会频繁超时，给自己找不痛快。

6.3 免费云服务的挑选逻辑，其实就三个标准

经历了这么多，我总结了一套挑选免费云服务的逻辑，分享给你们：

第一，看商业模式。免费服务一定要附着在成熟的商业模式上。它要么是巨头用来获客的入口，要么是现有付费产品的引流手段。纯粹因为情怀做免费服务的平台，早晚会因为成本问题改变规则。

第二，看规则边界。免费额度的边界必须足够清晰，让你知道自己在用什么、上限在哪。那些遮遮掩掩、不写清楚限制的服务，看起来大方，实则最容易出问题。

第三，看迁移成本。尽量选择基于开放标准或主流生态的服务。比如R2兼容S3协议、Pages支持Git集成，这意味着就算未来某天你想离开，数据和代码也能轻松迁走，不会被困在某个封闭生态里。

如果你也在找免费云服务，我建议先别急着注册一堆账号挨个试用，而是先按这三条标准把候选清单筛一遍，像我一样把需求列清楚。不然就会陷入我一开始那种“注册了十几个平台，真正常用的没有几个”的窘境。

最后再分享一个小技巧。免费云服务不是越多越好，而是越“少”越好。你只需要一个稳定的主力平台，把域名解析、静态托管、接口、图片存储都放到一个后台管理，运维成本会低很多。省下来的时间，足够你多写几篇文章、多做几个项目了。