1. 为什么“20 块钱小站”突然刷屏？它击中了当下开发者的三重疲惫
最近在几个技术社区和设计群，频繁刷到类似标题：“花不到 20 块钱 vibe coding 的小站，大家看看怎么样。”没有炫技的 Demo 视频，没有复杂的架构图，就一张干净的首页截图，配一句轻描淡写的邀请。但评论区却异常热闹——不是问“怎么部署”，而是问“域名在哪买”“备案麻烦吗”“能放简历链接不”。这背后不是又一个极简风模板的胜利，而是一次对当前建站生态的集体松动：当 SaaS 套餐动辄月付上百、VPS 配置文档厚过小说、甚至静态托管平台也开始推“专业版限速策略”时，“20 块钱”这个数字本身就成了最锋利的反讽。
我试过给某高校导师搭个人主页，对方明确说：“不要博客功能，不要评论系统，不要后台编辑，只要三页：首页、项目列表、联系方式。更新频率——一年一次。”结果我们花了三天调 Cloudflare Pages 的自定义域名 CNAME，两天处理 GitHub Actions 构建缓存失效问题，最后上线那天，他发来微信：“页面加载比我家路由器重启还慢。”这不是个例。大量真实需求其实极度朴素：一个可访问的、带 HTTPS 的、能稳定展示文字与图片的 HTML 容器，仅此而已。而“vibe coding”这个词的流行，恰恰说明开发者开始主动剥离“必须用最新框架”“必须上 CI/CD 流水线”“必须接入监控告警”的思维惯性——它不是降低标准，而是把注意力从“如何搭建基建”重新拉回到“我想表达什么”。
关键词里虽为空，但结合热搜词与实际传播语境，“vibe coding”本质是低决策成本 + 低维护负担 + 高情绪价值的三位一体。它不追求性能压测报告，但要求打开即见；不强调 SSR 渲染首屏，但拒绝白屏超过 800ms；不鼓吹微服务拆分，但要求删掉一个文件就能让整站下线。这种“可随时抽身”的底气，恰恰来自对底层链路的彻底掌控与刻意简化。所以本文不讲 Next.js App Router 的新特性，也不对比 Vercel 与 Netlify 的边缘函数定价差异——我们要还原的是：从零敲下第一个字符，到全球用户输入网址看到页面，中间真正不可省略的、花钱不超过 20 元人民币的六个物理环节，以及每个环节你必须亲手确认的三个关键状态。
提示：这里说的“20 块钱”不是营销话术，而是按 2024 年国内主流服务商公开标价、无任何优惠券、单次支付的现金支出上限。它覆盖的是“首次开通并完成基础配置”的刚性成本，不含续费、升级或额外服务。
2. 域名注册：11 元买断的不是字符串，而是互联网上的门牌号
所有“20 块钱小站”的起点，都始于一个域名。很多人误以为“.xyz”“.top”这类新顶级域（gTLD）便宜就是“不正规”，实则恰恰相反——它们因注册局政策透明、无中间商加价，反而成为性价比最高的选择。以“.xyz”为例，国内主流域名商（如某云、某网络）的首年价格普遍为 11 元，且支持支付宝/微信直付，无需绑定银行卡或进行企业认证。这个价格背后有其技术逻辑：ICANN（互联网名称与数字地址分配机构）对新 gTLD 的注册局管理费远低于传统“.com”“.cn”，而注册局又将成本优势直接传导至终端用户。
但关键不在“买多便宜”，而在“买完之后做什么”。我见过太多人付款后卡在第一步：以为付款成功=域名可用。实际上，域名注册只是获得一个字符串的“使用权”，要让它真正指向你的网站，必须完成 DNS 解析配置。这个过程存在两个极易被忽略的物理节点：
第一是WHOIS 信息实名认证。国内所有域名（无论后缀）均需通过注册商提交身份证正反面照片及手持证件照。审核通常需 12–24 小时，期间域名处于“待实名”状态，无法配置 DNS。曾有位 A 同学在周五下午 5 点提交认证，以为周末能继续操作，结果周一上午才收到审核通过短信——这 48 小时的等待，足以让一个“快速上线”的计划彻底脱节。我的建议是：注册域名后立即进入注册商后台，找到“实名认证”入口，一次性上传清晰、无反光、四角完整的证件照。尤其注意手持证件照中，身份证信息与本人面部必须同时清晰可见，且证件有效期需大于 3 个月。
第二是DNS 服务器（NS 记录）的强制切换。当你在注册商处购买域名时，系统默认会为你分配一组该注册商提供的 DNS 服务器（如 ns1.xxx.com, ns2.xxx.com）。但如果你后续想用 Cloudflare 或其他第三方 DNS 服务，就必须手动将 NS 记录修改为 Cloudflare 提供的地址（如 lara.ns.cloudflare.com）。这个操作看似简单，却是整个链路中最常出错的环节。错误示范包括：只修改了 A 记录却忘了切 NS、复制 NS 地址时漏掉末尾的英文句点、在注册商后台误点了“使用默认 DNS”按钮。实测下来最稳的操作路径是：先登录 Cloudflare，添加站点时获取其 NS 地址；再回到域名注册商后台，在“DNS 管理”或“域名解析”模块中，找到“NS 记录”设置项，逐条删除原有记录，粘贴 Cloudflare 提供的两条 NS 地址（注意保留末尾的“.”），保存后等待 10 分钟——此时域名才真正进入 Cloudflare 的 DNS 管控范围。
注意：NS 记录修改后，全球 DNS 缓存刷新需要时间，最长可达 48 小时。但 Cloudflare 控制台会实时显示“DNS 已激活”状态，这是比本地 ping 更可靠的判断依据。切勿在控制台未显示激活前，急于配置 CNAME 或 A 记录。
3. 静态托管：免费≠零配置，Cloudflare Pages 的隐藏开关必须手动开启
当域名完成实名认证并切换至 Cloudflare DNS 后，下一步是让代码“活起来”。此时绝大多数人会直奔 Vercel 或 Netlify，但它们的免费层存在一个隐蔽限制：自定义域名必须绑定付费计划（Pro 起步，月付 $20）才能启用 HTTPS 强制跳转。这意味着，如果你用 vercel.app 子域名，访问 http://xxx.vercel.app 会自动跳 https；但一旦绑定 yourname.xyz，http://yourname.xyz 就永远停留在非加密状态，浏览器地址栏显示“不安全”警告——这对个人站点而言，是体验上的致命伤。
Cloudflare Pages 则不同。它完全免费提供 HTTPS 全链路支持，且对自定义域名零门槛。但“免费”不等于“开箱即用”。我在帮某实验室部署论文集小站时，发现 70% 的失败案例源于一个被折叠在二级菜单里的开关：“Force HTTPS” 必须手动开启。这个选项默认关闭，位置在 Pages 项目设置 → “Custom domains” → 点击已添加的域名右侧的 “⋯” → “Edit” → 滑动到底部勾选 “Always use HTTPS”。不点这一下，哪怕你证书状态显示“Active”，用户仍可能通过 HTTP 访问，且搜索引擎会收录两个版本（HTTP/HTTPS），导致 SEO 权重稀释。
更关键的是构建配置。Pages 支持自动识别框架（如 React/Vue），但对纯 HTML/CSS/JS 项目，必须显式指定构建输出目录。常见误区是：把 index.html 直接放在仓库根目录，认为“没构建步骤，直接发布”。结果 Pages 会报错 “No build output found”。正确做法是：在仓库根目录创建wrangler.toml文件（即使不用 Workers），内容仅需三行：
name = "my-vibe-site" main = "./index.html" build = { command = "echo 'no build needed'", publish = "./" }其中publish = "./"明确告诉 Pages：所有文件（包括 index.html）都应作为静态资源发布。这个配置看似多余，实则是绕过 Pages 默认构建检测机制的必要声明。实测中，若省略此文件，Pages 会尝试运行npm run build，而空仓库根本不存在 package.json，最终构建失败。
另一个易被忽视的细节是CNAME 文件的强制存在。Pages 要求自定义域名必须通过 CNAME 记录指向cname.pages.dev，而非 A 记录。这意味着你在 Cloudflare DNS 后台添加的必须是类型为 “CNAME” 的记录，主机名为 “@”（代表根域名），目标值为 “your-project.pages.dev”。很多新手误填为 A 记录并指向某个 IP，结果页面始终 404。验证方法很简单：在终端执行dig yourname.xyz CNAME +short，返回结果必须是your-project.pages.dev.（末尾带点）。若返回空或 IP 地址，则 DNS 配置错误。
4. HTTPS 证书：Let’s Encrypt 的自动化不是魔法，而是三次握手的精密 choreography
当域名 DNS 指向 Pages、Pages 构建成功、CNAME 记录生效后，你可能会在 Pages 控制台看到 “SSL/TLS: Active” 的绿色标识。但这只是表象。真正的 HTTPS 可用性，取决于 Let’s Encrypt 证书颁发机构（CA）与 Cloudflare、Pages 之间的一套精密协作流程。这套流程不是“一键生成”，而是包含三次关键握手，任何一环中断都会导致证书状态卡在 “Pending” 或 “Error”。
第一次握手发生在Cloudflare 与 Let’s Encrypt 之间。当你在 Cloudflare DNS 中为域名开启 “Proxy status: Proxied”（橙色云图标）后，Cloudflare 会主动向 Let’s Encrypt 发起证书申请。这个过程依赖于域名的 DNS 记录已正确指向 Cloudflare 的 NS 服务器（前文所述），且 Cloudflare 能通过 HTTP-01 挑战验证你对该域名的控制权。验证方式是：Let’s Encrypt 向http://yourname.xyz/.well-known/acme-challenge/xxx发送 GET 请求，Cloudflare 必须能返回预设的随机字符串。如果此时你的 Pages 项目尚未部署，或 CNAME 记录未生效，Cloudflare 就无法响应挑战，证书申请失败。
第二次握手发生在Cloudflare 与 Pages 之间。Pages 在收到 Cloudflare 的证书请求后，会生成一对公私钥，并将公钥证书链回传给 Cloudflare。这个过程要求 Pages 项目的构建状态为 “Success”，且自定义域名已在 Pages 后台完成添加（而非仅 DNS 配置）。我曾遇到一个案例：A 同学 DNS 配置正确，Pages 构建成功，但忘记在 Pages 控制台的 “Custom domains” 页面点击 “Add custom domain” 按钮。结果 Cloudflare 一直收不到 Pages 的证书响应，状态长期显示 “Waiting for certificate”。
第三次握手是浏览器与 Cloudflare 之间的 TLS 握手。当用户访问https://yourname.xyz时，浏览器会向 Cloudflare 请求证书，Cloudflare 返回 Pages 提供的证书链，并用私钥解密会话密钥。这个环节的稳定性，取决于证书是否在 Cloudflare 侧完成 OCSP Stapling（在线证书状态协议装订）。OCSP Stapling 能让 Cloudflare 在 TLS 握手时一并发送证书吊销状态，避免浏览器额外向 CA 查询。Pages 默认开启此功能，但前提是证书已由 Let’s Encrypt 正常签发。若前两次握手任一失败，OCSP Stapling 就无从谈起，用户可能遭遇 “NET::ERR_CERT_AUTHORITY_INVALID” 错误。
提示：验证 HTTPS 是否真正生效，最可靠的方法不是看浏览器锁图标，而是访问
https://yourname.xyz/cdn-cgi/trace。返回结果中colo=字段显示数据中心位置，http=字段显示h2（HTTP/2），tls=字段显示TLSv1.3，且无error=字段——这表示 TLS 握手全程畅通。
5. 内容交付：别被“全球 CDN”迷惑，首屏加载速度取决于三个物理距离
“全球 CDN 加速”是所有托管平台的宣传标配，但对个人小站而言，它的实际价值常被高估。Pages 和 Cloudflare 的 CDN 节点确实遍布全球，但决定你首页加载快慢的，从来不是节点数量，而是三个具体的物理距离：
第一是用户设备到最近 CDN 边缘节点的距离。例如，北京用户访问，Cloudflare 会将其路由至上海或东京节点；而成都用户可能被导向重庆或深圳节点。这个距离决定了 TCP 连接建立的 RTT（往返时延），通常在 10–30ms。Pages 的优势在于，它与 Cloudflare 深度集成，DNS 解析与边缘路由由同一系统调度，避免了传统架构中 DNS 解析（如阿里云）与 CDN 节点（如网宿）分离导致的二次跳转延迟。
第二是CDN 边缘节点到 Pages 源站（Origin）的距离。这里有个关键事实：Pages 的源站并非物理服务器，而是 Cloudflare 的 KV 存储或 R2 对象存储。当你执行git push，Pages 构建产物会被写入 R2，而 R2 的数据副本会自动同步至 Cloudflare 全球所有区域。因此，边缘节点读取静态资源时，走的是内部高速网络，RTT 通常低于 5ms。这与传统 VPS 架构（边缘节点需通过公网回源到上海机房）有本质区别。
第三，也是最容易被忽视的，是HTML 文档内资源的加载路径距离。比如你的 index.html 中引用了<script src="https://cdn.jsdelivr.net/npm/vue@3.4.0/dist/vue.global.js"></script>，那么浏览器在解析 HTML 后，会发起第二次 DNS 查询（jsdelivr.net）、TCP 连接、TLS 握手，再下载 JS 文件。这个过程与你的 Pages 站点完全无关，且受制于 jsdelivr 的 CDN 质量。实测数据显示，引入一个外部 CDN 资源，平均增加首屏时间 120–200ms。因此，“vibe coding” 的最佳实践是：所有 CSS/JS/图片，全部内联或存于同一仓库，通过相对路径引用。例如，将 vue.min.js 下载后放入/js/目录，HTML 中写<script src="/js/vue.min.js"></script>。这样，所有资源均由 Pages+Cloudflare 统一调度，首屏加载变成单次 HTTP/2 多路复用请求，实测 TTFB（首字节时间）稳定在 30–60ms。
注意：图片资源务必压缩。未压缩的 PNG 可能达 2MB，而 TinyPNG 优化后常低于 200KB。Pages 不提供图片压缩服务，必须在上传前完成。推荐命令行工具
squoosh-cli：npx squoosh-cli --quality 80 --format webp ./src/img/*.png，批量转 WebP 格式，体积减少 60% 以上。
6. 成本闭环：11 元域名 + 0 元托管 = 真正的 20 元以内，但必须避开三个隐形收费陷阱
现在我们来算一笔硬账：域名 11 元（.xyz 首年），Pages 托管 0 元，Cloudflare DNS 0 元，HTTPS 0 元。总支出 11 元，远低于 20 元红线。但现实中，不少人的实际支出突破了 30 元，原因全在三个隐形收费陷阱：
陷阱一：域名隐私保护的强制捆绑销售。国内部分注册商在结算页默认勾选“Whois 隐私保护”服务，价格 15–20 元/年。这个服务本意是隐藏你的身份证号和手机号，防止被爬虫抓取。但对个人小站而言，它毫无必要——因为 WHOIS 信息仅用于 ICANN 合规审计，普通用户无法通过公开渠道查询国内已实名域名的详细信息。更关键的是，Cloudflare 提供免费的 Whois 隐私保护：当你将域名 NS 切换至 Cloudflare 后，在 Cloudflare 仪表盘 → “DNS” → “Whois Privacy” 中开启即可，无需额外付费。因此，注册域名时，务必取消勾选注册商提供的隐私保护选项。
陷阱二：SSL 证书的“高级版”诱导消费。某些注册商会弹窗提示：“您的域名未配置 HTTPS，立即购买 OV 证书（¥199/年）”。这是典型的制造焦虑。Pages + Cloudflare 组合使用的正是 Let’s Encrypt 的 DV（域名验证）证书，安全性与 OV 无异，唯一区别是证书中不显示企业名称。而个人站点根本不需要向访客证明“我是某某公司”，DV 证书完全满足需求。所有操作均在 Pages 和 Cloudflare 后台免费完成，无需任何第三方证书采购。
陷阱三：“一键部署”插件的订阅陷阱。GitHub Marketplace 中存在一些标榜“Pages 一键部署”的 Action，它们往往要求你授权其读取仓库权限，并在首次使用时引导你订阅“Pro Plan（$9/月）”。真相是：Pages 原生支持 GitHub 集成，只需在 Pages 设置中连接 GitHub 账号，选择仓库和分支，即可自动触发构建。所谓“一键插件”，不过是封装了相同的 API 调用，却用订阅制收割小白。我的做法是：永远使用 Pages 官方集成，拒绝任何第三方部署工具。
最后强调一个财务事实：所有费用均为一次性支付，无月租、无续费提醒、无自动扣款。.xyz 域名首年 11 元，次年续费仍为 11 元（价格锁定）；Pages 永久免费；Cloudflare DNS 永久免费。这意味着，你今天花 11 元开通的服务，十年后依然有效，且无需任何操作。这种“一次付费，永久拥有”的确定性，正是对抗当下 SaaS 订阅制焦虑的核心底气。
7. vibe coding 的终极心法：用“可删除性”倒逼技术决策
写到这里，你可能已经能复现整个流程。但“vibe coding”之所以形成一种文化现象，绝不仅因技术路径简单。它背后有一套隐性的工程哲学：以“可删除性”为最高优先级，反向筛选所有技术组件。
什么是“可删除性”？就是当你某天突然不想维护这个小站了，能否在 5 分钟内，通过三个操作让它彻底从互联网消失：1）登录域名注册商，关闭 DNS 解析；2）登录 Pages 后台，删除项目；3）清空 GitHub 仓库。整个过程不依赖任何客服、不产生违约金、不留下残留数据。我给自己定的铁律是：任何需要“联系客服解绑”“等待工单处理”“支付解约费”的服务，一律不采用。
这套心法直接决定了技术选型。比如，为什么不用 WordPress？因为它删除时需登录数据库清空表、FTP 删除文件、后台禁用插件，稍有遗漏就会残留 admin.php 后门。为什么不用 Firebase Hosting？因为删除项目后，其自动生成的web.app子域名仍会跳转至 404 页面，且 Firebase 控制台删除项目需二次确认，流程冗长。而 Pages + Cloudflare 的组合，每个环节都是原子化操作：关 DNS，全球解析立即失效；删 Pages 项目，R2 存储自动清空；删 GitHub 仓库，源码彻底消失。三者互不耦合，删除顺序任意。
这种“可删除性”也重塑了内容生产习惯。我不再写“未来计划更新 XX 功能”，而是把每篇文章都当作独立 HTML 文件：/blog/2024-06-15-hello.html。没有数据库，没有 CMS 后台，没有分类标签云。更新就是改一个文件，推送即生效。当某天我觉得“这些文字不再代表我”，直接rm blog/2024-06-15-hello.html && git push，世界就清静了。这种轻盈感，是任何重型框架都无法提供的。
最后分享一个小技巧：在 Pages 项目根目录创建一个
DELETE_ME.txt文件，内容只有一行：“This site is deprecated as of [date]”。当你要下线时，把它改成index.html并推送。全球用户访问原域名，看到的不再是空白，而是一句坦诚的告别。这比 404 页面更符合 vibe coding 的精神——技术可以消失，但态度必须诚实。
