muxin ✦ space

这篇文章最早其实只是我平板上的手写笔记。后来真的把网站搭起来、部署到 Cloudflare、再把阿里云域名接进来之后，我发现有些东西只靠课堂式概念记忆是不够的，必须结合一次真实落地，很多判断才会变清楚。

所以这篇内容不只是“我学到了什么”，也是一次完整的建站取舍记录：为什么我最后没有直接上重交互框架，为什么 Astro 适合现在这个站，以及 Cloudflare Pages 和阿里云域名到底应该怎么配合使用。

我想做的不是重产品，而是内容型个人站

先把目标说清楚，很多技术选型其实到这里就已经定了。

我现在这个网站的核心不是做一个复杂 Web App，而是做一个适合长期生长的个人内容站。它主要承载几类东西：

  • 学习过程里的知识整理
  • 项目复盘和工程拆解
  • 公开的技术分享
  • 个人表达和长期沉淀

这意味着我真正关心的不是“功能能不能做得很炫”，而是下面几件更基础的事：

  • 页面够不够轻
  • 内容写起来顺不顺手
  • 后续维护成本高不高
  • 部署链路够不够简单
  • 以后要加局部交互时会不会很痛苦

只要目标从“做产品”切换成“做内容站”，框架选择就会变得非常具体。

为什么不是 Vue 或 React 主导整站

Vue 3 和 React 当然都能做个人网站，而且如果目标是做偏产品型、工具型、后台型页面，它们非常自然。

问题不在于它们不强，而在于它们太擅长解决“高交互应用”的问题了。

如果一个站点从一开始就需要这些东西：

  • 大量客户端状态
  • 复杂表单和交互流程
  • 用户登录后的个性化行为
  • 整页由前端运行时接管

那用 Vue 或 React 做主框架是很顺手的。

但我现在的网站并不是这个方向。它的主体其实是文章、项目卡片、关于页、分享页、归档页。这些页面本质上是内容，不是复杂前端应用。

在这种前提下，如果一开始就把整站按“重交互产品”的方式来建，很多精力会被消耗在：

  • 运行时逻辑
  • 状态组织
  • 不必要的客户端成本
  • 还没开始写内容，就先背上较重的工程心智负担

这不是做不到，而是性价比不高。

为什么是 Astro

我最后选 Astro，核心原因很朴素：它和我当前网站的目标是同向的。

Astro 特别适合这类场景：

  • 博客
  • 文档
  • 知识分享站
  • 项目展示站
  • 内容型个人主页

因为它默认就是“内容优先、静态优先”的思路。

对我来说，这几个点尤其重要。

1. 默认少发 JavaScript

很多框架默认会让浏览器接管更多页面行为，而 Astro 的思路是：

  • 能在构建阶段生成好的内容，就先生成好
  • 能直接输出静态 HTML，就不要急着把整页做成前端应用
  • 真正需要交互的部分，再按需加载客户端逻辑

这会让内容页天然更轻。

2. Markdown 进入内容流非常顺

个人网站要长期写下去，内容载体一定要舒服。

Astro 的内容体系和 Markdown 配合得很自然，很适合拿来做：

  • 知识分享文章
  • 项目记录
  • 系列笔记
  • 长期归档

它不是那种“理论上能写文章”，而是真的把内容写作当成一等公民看待。

3. 适合渐进增强

我并不是完全不要交互，而是不希望在最开始就为了少量交互把整站变重。

如果以后我要加这些能力：

  • 搜索
  • 标签筛选
  • 评论系统
  • 局部动态组件

Astro 也能很好接住。也就是说，它不是“只能做静态站”，而是允许我先把内容站跑顺，再在必要处增加交互。

4. 很适合当前阶段的节奏

我现在更在意的是先把这个站稳定上线、持续更新，而不是先给自己套一个很重的产品工程模型。

Astro 的优势就在于，它更鼓励你先把这些事情做好：

  • 内容结构
  • 页面叙事
  • 信息组织
  • 发布节奏

这和我现在做个人网站的目标是完全一致的。

Astro 到底是什么

如果用一句话概括，我会把 Astro 理解成一个偏内容站的现代 Web 构建框架。

它的核心理念可以理解为三句：

  • 默认尽量少发 JavaScript
  • 优先输出静态 HTML
  • 真正需要交互时，再局部激活组件

这和很多传统前端项目“整页由客户端接管”的思路不一样。

所以在内容型网站里，Astro 的好处特别直接：

  • 首屏更轻
  • 页面结构更清晰
  • SEO 更自然
  • 不需要为不必要的交互付出运行时成本

理解 Astro，绕不开岛屿架构

如果只记一个 Astro 概念，我觉得最值得先记住的是“岛屿架构”。

你可以把一个网页想成一整块陆地。

传统前端应用常常是：整块陆地都要通电，整页都加载大量 JavaScript，然后交给浏览器接管。

而 Astro 的做法更像是：

  • 大部分区域直接输出成静态 HTML
  • 只有少数真的需要交互的区域，被做成“岛屿”
  • 这些岛屿再单独加载 JavaScript

这样一来，页面的主体依然很轻，但你又不会失去动态能力。

这件事为什么重要？因为个人网站的大部分页面其实都属于：

  • 文章正文
  • 项目介绍
  • 关于页
  • 首页文案和卡片

这些内容本身没有必要一上来就全部水合成前端应用。真正可能需要交互的，通常只是局部模块，比如搜索框、标签筛选或者评论区。

所以岛屿架构的价值，不只是“一个新概念”，而是它直接把网站里“静态部分”和“动态部分”拆清楚了。

client:load 这样的客户端指令在解决什么

在 Astro 里，如果某个组件确实需要在浏览器里运行，就可以写成：

<SomeComponent client:load />

它的意思不是“这个组件很高级”，而是很朴素地表达一件事：这个组件需要在客户端激活。

client:load 比较适合：

  • 页面打开后立刻就要工作的交互组件
  • 用户第一时间就会碰到的动态区域

比如：

  • 搜索输入框
  • 交互式导航
  • 立即可点击的动态模块

它的核心好处在于，你只让真正需要交互的部分加载 JS，而不是为了一个小功能把整页都拖进前端运行时。

对内容站来说，这个思路特别重要，因为它能让我们同时保住两件事：

  • 文章页依然很轻
  • 局部功能依然可以很灵活

我的部署方案为什么是 Astro + Cloudflare Pages + 阿里云域名

这次真正跑通之后，我觉得这套组合对个人站非常顺手：

  • 框架：Astro
  • 部署平台：Cloudflare Pages
  • 域名注册与管理：阿里云

这里每一层都在做不同的事。

Cloudflare 在这里负责什么

当前这套网站里，Cloudflare 主要扮演三个角色：

  • 静态站部署平台
  • CDN 分发层
  • 域名接入和 HTTPS 托管层

如果你用的是 Cloudflare Pages，它对这种 Astro 内容站非常友好，因为它本身就很适合：

  • GitHub 直连
  • 自动构建
  • 自动部署
  • 后续只靠 git push 更新站点

阿里云在这里负责什么

阿里云在这套方案里主要不是“放网站代码”的地方，而是：

  • 域名注册商
  • 域名管理平台

也就是说，域名可以在阿里云买，但网站本体依然可以部署在 Cloudflare Pages。两者不是互斥关系。

Cloudflare Pages 的正确部署链路

这部分是我这次踩坑之后觉得最值得讲清楚的地方。

如果你当前做的是一个 Astro 静态站，最顺的部署方式其实非常直接：

第一步：先保证本地构建没问题

在接 Cloudflare 之前，先在本地跑通：

npm install
npm run build
npm run check

这一步特别重要。很多看起来像 Cloudflare 的报错，根源其实是本地项目就没有构建成功。

第二步：把仓库推到 GitHub

Cloudflare Pages 最舒服的方式就是直接连 Git 仓库。

一般流程就是：

  1. 本地提交代码
  2. 推送到 GitHub
  3. 确保 main 之类的生产分支是最新的

第三步：在 Cloudflare 里创建 Pages 项目

这里一定要选对产品类型。

对当前这个站来说，应该创建的是：

  • Pages

而不是：

  • Workers
  • Workers Builds

这个区别看起来像小事，但实际上是这次踩坑最核心的一环。产品一旦选错，后面整个部署链路都会偏掉。

第四步：连接 GitHub 仓库并填写构建配置

当前这个 Astro 项目推荐配置是：

Framework preset: Astro
Build command: npm run build
Build output directory: dist
Root directory: /
Node version: 20 或 22

保存之后，Cloudflare 会自动：

  1. 拉取仓库
  2. 安装依赖
  3. 执行 npm run build
  4. 发布 dist

首次成功后，它会先给一个默认的 Cloudflare 二级域名。

第五步：以后更新只要继续推仓库

这也是这套链路最舒服的地方。

后续更新通常只需要：

  • 本地改代码
  • git add / git commit
  • git push

Cloudflare Pages 会自动重新构建并部署。也就是说，它更像一个持续发布的站点流水线，而不是每次都手动上传文件。

这次最关键的 Cloudflare 踩坑

如果只看官方文档，很多概念其实都认识；但真正开始配的时候，最容易卡住的是产品边界没分清。

这次我觉得最关键的几个坑如下。

1. 把 Pages 和 Workers 搞混

如果你的项目本质上是：

  • Astro 静态站
  • 输出目录是 dist
  • 没有 Worker 脚本入口

那就应该走 Pages。

如果误走成 Workers，你后面会看到很多看起来很专业、其实方向完全错了的配置，比如：

  • npx wrangler deploy
  • npx wrangler versions upload

这些命令主要是给 Worker 用的，不是给当前这类静态站用的。

2. 以为部署命令应该写 wrangler deploy

这个坑特别典型。

wrangler deploy 期待的是一个 Worker 脚本入口，比如 src/index.ts。但当前这个网站只有静态构建产物，没有这种 Worker 入口，所以这样配就会报“缺少 entry-point”之类的错误。

如果你走的是标准 Pages + Git 流程，核心应该是让 Cloudflare 去执行构建，而不是自己手动把它当 Worker 发出去。

阿里云域名应该怎么接到 Cloudflare

如果域名是在阿里云买的，比较顺的方式不是把站点搬到阿里云服务器，而是这样理解：

  • 域名继续留在阿里云名下
  • DNS 解析控制权切给 Cloudflare
  • 网站本体继续部署在 Cloudflare Pages

实际流程可以拆成几步。

1. 在阿里云购买域名并完成实名

这一步本质上是获得你的网址入口，比如：

  • .com
  • .space
  • .xyz
  • .dev

买完之后通常还需要完成实名信息，这属于域名层面的基础流程。

2. 把域名添加到 Cloudflare

在 Cloudflare 里 Add a site，输入你的域名之后，它会分配给你两条 nameserver。

它们看起来通常像这样：

  • xxx.ns.cloudflare.com
  • yyy.ns.cloudflare.com

3. 回阿里云修改 nameserver

然后回到阿里云域名控制台，把原来阿里云默认的 nameserver 替换成 Cloudflare 给你的那两条。

这一步做完之后，域名解析控制权就交给 Cloudflare 了。

4. 等待 Cloudflare 激活，再绑定到 Pages

等域名状态在 Cloudflare 里变成激活后，就可以去 Pages 项目里添加自定义域名。

一般会绑定：

  • 主域名，例如 muxin.space
  • 如果需要，再加 www.muxin.space

这样，你的网站就从 Cloudflare 默认二级域名切换成自己的正式域名了。

域名、服务器、部署平台，这几个概念不要混

做个人网站时，很多人第一次会把这些东西混在一起，但它们其实完全不是同一层。

域名是什么

域名就是访问入口，是别人记住你网站的名字。

比如 muxin.space 是域名，但它不是网站代码本身，也不是运行环境本身。

服务器或托管平台是什么

这是网站真正被放置和运行的地方。

如果是我现在这套方案，网站主要托管在 Cloudflare Pages。所以真正负责把页面发给用户的，是 Cloudflare 的托管和 CDN 网络，而不是“阿里云买了域名”这件事本身。

DNS 或 nameserver 是什么

可以把它理解成“域名该把访问请求交给谁来解析和分发”。

当我把阿里云域名的 nameserver 改成 Cloudflare 的 nameserver，本质上就是把“这个域名怎么找到网站”的控制权交给 Cloudflare。

把这三层拆开后，整个部署逻辑就会清晰很多：

  • 阿里云：买域名
  • Cloudflare：接管解析、提供 HTTPS、托管站点
  • Astro：负责把网站内容构建出来

备案和国内访问，要怎么看

这也是很多人刚建站时最容易误解的问题。

一个常见误区是：以为买了国内注册商的域名，就等于网站天然是国内部署。

其实不是。

是不是要考虑 ICP 备案，关键不在于域名在哪里买，也不主要看后缀，而是要看你的网站托管在哪里。

如果网站部署在中国大陆节点，通常就要认真考虑备案问题；如果网站托管在 Cloudflare 这种境外网络，逻辑就不是“买了阿里云域名就自动变成国内站”。

所以更准确的理解应该是：

  • 域名注册地不等于部署地
  • 域名后缀不直接决定访问速度
  • 是否备案更多取决于托管位置

这次搭站之后，我对选型的结论

回头看这次选择，我觉得最重要的结论不是“Astro 比别的框架更高级”，而是：它更适合我当前这个网站阶段。

我现在需要的是一个：

  • 轻量
  • 能稳定更新
  • 能持续写内容
  • 能顺手展示项目
  • 以后还能渐进增强

的网站。

从这个目标出发，Astro + Cloudflare Pages + 阿里云域名 这套组合已经足够好用，而且心智负担不重。

如果以后网站往更强的产品形态演化，再去补更多动态能力、前端状态和服务端能力，是完全来得及的。但在现在这个阶段，先把内容站搭稳、写顺、发起来，本身就是最正确的工程取舍。

最后一段总结

如果把这篇文章压缩成一句话，那就是：

对一个以知识分享、项目复盘和长期沉淀为主的个人网站来说，Astro 不是“最炫”的选择，但它很可能是当前阶段最合适的选择；而当你把 Cloudflare Pages 的部署链路和阿里云域名的接入逻辑理顺之后，整个个人站会变成一套非常轻、非常稳、也非常适合长期写下去的系统。