第一次搭网站，先选生成方式，再选部署平台

我见过最常见的建站顺序，几乎是反的

很多人先在 WordPress、Hexo、Next.js 和各种托管平台之间做选择，接着买域名、买服务器，最后才问：这个网站到底需要怎样更新？

顺序应该倒过来。先看内容从哪里来，更新时要不要重新构建，访问页面时是否需要服务器计算，数据和账号准备由谁长期维护。四个答案出来以后，工具范围会自己缩小。

如果只是公开文章、作品或项目文档，静态网站往往已经够用；需要多人后台写作，再看内容管理系统；真正需要登录、订单和实时数据，才进入 Web 应用。

这篇文章不替你选一个“最强框架”。它先把本地文件、构建、仓库、托管、域名和 DNS 放回各自的位置，让第一次上线有一条能够解释的路径。

一个网站至少经过五层

第一层：内容

内容是标题、正文、图片、链接和页面数据。

它可以直接写在 HTML，也可以存成 Markdown、数据库记录或后台表单。内容格式决定后续怎样编辑，但它还不是公开网站。

第二层：页面生成

浏览器最终需要 HTML、CSS 和 JavaScript。

如果你直接写 HTML，这一层几乎没有额外转换。如果你写 Markdown、使用 Hexo 或其他生成器，就需要一次构建，把源文件变成浏览器能读取的页面。

当前 Kenton Blog 就属于这种模式：文章正文保存在 Markdown，构建脚本生成独立 HTML、首页、RSS 和 sitemap。

第三层：代码仓库

GitHub 仓库负责保存版本、协作和回退。它不是必须的，但能让你知道某次修改发生了什么，也方便托管平台在每次推送后重新构建。

仓库存在不等于网站已经公开。它只说明源文件或构建结果被保存到了远程位置。

第四层：托管平台

托管平台把生成后的文件放在持续联网的基础设施上。

GitHub Pages 和 Cloudflare Pages 都可以托管静态网站。Cloudflare Pages 官方文档说明，普通静态 HTML 也能部署，不必先选择框架；成功部署后会得到一个 pages.dev 子域名。

第五层：域名与 DNS

托管平台提供的默认地址已经可以访问。自定义域名只是把自己的名字指向这个站点。

DNS 负责解析，不负责生成页面。域名打不开时，可能是 DNS、证书、托管配置或网站文件问题，不能把所有错误都归给“域名没生效”。

先判断你属于哪一种网站

纯静态网站

适合：

个人博客。
项目文档。
产品介绍页。
作品集。
不需要登录和数据库的内容页。

优点是结构简单、攻击面较小、托管成本低。缺点是需要通过文件或构建流程更新内容。

如果你的需求只是“公开一组会持续更新的文章”，静态站通常是第一推荐。

内容管理系统

适合：

多人通过后台写作。
需要评论、用户角色和插件。
不希望每次更新都操作代码仓库。

WordPress 是这一类。它提供后台和数据库，但也带来服务器、更新、插件安全、备份和恢复责任。

Web 应用

适合：

用户登录。
个性化数据。
实时操作。
支付、订单或复杂表单。
需要服务端逻辑的产品。

这时前端框架、API、数据库和部署方式才成为核心。不要为了一个只有五个页面的博客，提前承担整套应用维护。

第一次成功只需要一个文件

创建一个新目录，在里面建立 index.html：

<!doctype html>
<html lang="zh-CN">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>我的第一个网站</title>
</head>
<body>
  <h1>网站已经开始工作</h1>
  <p>这是一个真实的 HTML 页面。</p>
</body>
</html>

直接双击可以打开，但本地文件地址和真实网站环境不同。电脑已经安装 Python 时，可以在这个目录运行：

python3 -m http.server 8000

然后打开：

http://localhost:8000

成功标志不是终端出现一行文字，而是浏览器显示标题和段落，刷新后仍然存在。

停止服务可以回到终端按 Control + C。

从本地页面到公开页面

方案一：GitHub Pages

GitHub 官方快速开始提供了从仓库创建 Pages 站点的路径。它适合已经使用 GitHub，并希望仓库与网站紧密对应的人。

最小流程是：

创建仓库。
上传 index.html。
在仓库设置中启用 Pages。
选择发布来源。
等待公开地址生成。
从无登录浏览器打开公开 URL。

最后一步很重要。自己登录 GitHub 时能看到页面，不代表普通访客也能访问。

方案二：Cloudflare Pages

Cloudflare Pages 支持 GitHub 或 GitLab 集成，也能部署普通静态 HTML。

对于不需要构建的静态目录，官方文档允许使用自定义输出目录，并说明站点根目录需要可用的 index.html，否则默认地址可能返回 404。

使用 Git 集成时，要明确：

哪个仓库。
哪个分支。
是否需要构建命令。
构建结果在哪个目录。
哪次推送触发了部署。

部署完成后先验证 pages.dev 地址，再接自定义域名。这样 DNS 出错时，能确认网站本身是否正常。

构建命令和输出目录是什么

这是新手最常卡住的地方。

假设你用 Markdown 写文章，构建脚本把页面生成到 dist 目录：

content/
  article.md

构建之后：

dist/
  index.html
  articles/
    article.html

托管平台需要的是 dist，而不是 content。

构建命令负责产生 dist。

输出目录告诉平台应该公开哪一批文件。

如果填错，常见结果包括：

构建成功但页面 404。
首页能开，文章路径不存在。
平台公开了源码而不是生成页面。
本地正常，线上缺图片或 CSS。

排查时先看平台构建日志，再确认公开目录里是否真的存在 index.html。

域名应该最后接

自定义域名至少涉及：

域名注册商。
DNS 托管。
Pages 项目。
DNS 记录。
HTTPS 证书。

不要同时修改所有层。

更稳的顺序是：

默认平台地址可以访问。
自定义域名添加到正确项目。
按平台提示配置 DNS。
等待平台确认域名。
HTTPS 正常。
www 与根域名跳转符合预期。

DNS 页面显示一条记录，不代表浏览器已经拿到正确内容。使用无痕窗口或另一网络再次访问，避免本地缓存造成误判。

怎样判断网站真的发布成功

至少完成下面七项：

首页返回正确标题。
一个文章详情页可以访问。
CSS 与图片没有丢失。
手机宽度没有横向滚动。
默认平台地址和自定义域名行为清楚。
sitemap 与 RSS 在需要时能打开。
更新一篇文章后，知道哪次构建把它发布出去。

“平台显示绿色”只能证明构建任务通过。公开 URL 的实际回读，才证明用户能看到。

404 时按这五层排查

本地文件层

输出目录里有没有 index.html，文件名大小写是否一致。

构建层

构建命令是否退出成功，生成文件是不是写到了另一个目录。

托管层

项目选择的分支、构建命令和输出目录是否正确。

路径层

页面使用绝对路径还是相对路径，子目录部署时资源地址是否变化。

域名层

默认平台地址能否访问。如果能，问题更可能在自定义域名、DNS 或证书。

不要看到 404 就立刻换框架。先找到第一层缺少的文件。

费用从哪里出现

静态站入门可以使用免费托管，但长期仍可能有：

域名续费。
超出免费额度的构建或流量。
图片存储。
邮件与表单服务。
分析工具。
付费主题或插件。
维护时间。

价格会变化，文章不写死套餐数字。使用前查看平台当前价格页和限制。

我给第一次建站者的默认选择

如果你只是要博客、项目页或作品集：

内容先用 Markdown 或简单 HTML。
生成静态文件。
用 GitHub 保存版本。
用 GitHub Pages 或 Cloudflare Pages托管。
默认地址成功后再绑定域名。
不先买服务器。
不先安装数据库。

当你真正需要登录、后台和动态数据时，再进入 WordPress 或 Web 应用。

第一次建站做到这里就够了：你知道内容放在哪，哪个命令生成页面，哪批文件被托管，域名指向哪里，404 时先查哪一层。技术栈可以以后换，这条路径必须先讲得清。

SOURCE AND VERIFICATION

来源与核验边界

参考站页面只提供选题入口；网站结构、部署概念和当前限制以官方资料及 Kenton Blog 的真实静态结构重新组织。

核验状态：对照 GitHub Pages、Cloudflare Pages 与 MDN 官方资料核验；使用当前 Kenton Blog 静态生成结构作为案例，未在本轮创建新的生产部署，核验日期 2026-08-11。

ONE PRACTICAL NEXT STEP

把你的真实流程带过来

如果你已经知道目标，却不知道应该先改工具、流程还是内容，把当前步骤和失败证据发来。我会先帮你判断最短路径。

查看 OpenClaw 安全部署