企业官网建设流程全解析

1. 先想清楚再动手：你的博客到底需要什么

很多人一提“博客搭建”就直接去搜教程，看到推荐 Hexo 就装 Hexo，看到推荐 WordPress 就装 WordPress，折腾一晚上域名买好了、主题换了一堆，结果一篇文章都没写出来。我见过太多这种例子，包括我自己第一回也是这么过来的。

博客搭建这件事，最难的部分从来不是技术，而是想清楚三个问题：你写给谁看、你打算写多久、你能忍受多少维护成本。这三个问题直接决定了你的技术选型，选错了后面全是坑。

先说“写给谁看”。如果你的博客是纯粹的个人笔记，记录学习过程、踩坑记录，那么静态站点生成器是最合适的——轻量、快、不用管服务器，写完一条git push就完事。如果你想做一个带评论、带用户体系的社区型站点，那静态博客就得挂第三方评论服务，或者直接上动态系统。如果你是想靠博客做流量变现、做 SEO 排名，那你的需求又会不一样，对收录、速度、部署位置都有要求。

再说“写多久”。这个听起来像废话，但直接影响技术选型。很多人一开始图新鲜，选了最复杂的方案：VPS + Docker + 动态博客 + 数据库，结果写了三篇就吃灰，服务器一个月几十块倒是小事，关键是每次想写点东西，光打开后台就卡两下，热情没了。我自己后来的经验是：前期用最简单的方案，等你真的坚持写了半年以上、内容超过五六十篇，再考虑迁移更强大的系统。千万别在没写几篇文章的时候就把基建搞得太重。

最后是“维护成本”。博客这个东西，内容创作才是核心，工具应该是隐形 的。如果你每天打开电脑要花十分钟去处理环境问题、升级依赖、修复部署脚本，那这博客迟早废。静态博客的维护成本在写作阶段几乎为零，这是它最大的优势。

顺着这个思路，下面我把整体链路拆开讲清楚，从选型、本机写作到线上部署，每一步背后的逻辑和实操细节都会交代到位。

2. 技术选型：为什么静态博客是大多数人的最优解

2.1 静态与动态两条路线的选择逻辑

所谓静态博客，就是网站在访问者访问之前，就已经把每个页面用 HTML 文件生成好了。它没有数据库、没有后端程序，服务器做的唯一事情就是把文件返回给浏览器，本质和下载文件没区别。

动态博客则相反，每个用户访问的时候，后端程序要从数据库里把文章取出来，再渲染成 HTML 返回。好处是功能丰富、交互强，但代价是你得维护一个常驻运行的服务。

拿开饭店打个比方：静态博客像是盒饭档口——菜已经做好摆在那里，谁来直接端走，速度快、成本低、出不了大乱子。动态博客像是现炒的餐厅——客人点了菜才下锅，口味灵活（能交互、能登录），但你要雇厨师（维护程序）、备菜（管理数据库），一个环节出错就上不了菜。

基于这个对比，绝大多数人的选择应该是静态博客。如果你是一个技术人，内容以图文为主，不需要用户注册、不需要实时交互，静态博客的体验是碾压级的。除了极少数场景——比如你要做付费课程、要接用户登录体系、要做复杂的站内搜索——动态博客才值得考虑。

2.2 静态站生成器怎么选：Hexo 凭什么当主力

静态站生成器有很多，主流的有 Jekyll、Hugo、Hexo，还有近几年流行的 Astro、VitePress 之类。说下我的真实感受。

Jekyll 和 GitHub Pages 是原生搭档，但它基于 Ruby 生态，本地环境有时候会让人抓狂，尤其是 Windows 上装 Ruby 那一套东西，容易让新手劝退。Hugo 是 Go 写的，速度极快，号称几千篇文章几秒构建完，但它的模板语法和内容组织方式有一定的学习门槛，主题的生态也不如 Hexo 丰富。

Hexo 用 Node.js 写，安装只要一行命令，主题和插件的数量在静态博客圈子里数一数二。它的学习曲线比较平缓：写作就是 Markdown，命令行就四五个常用命令，主题随便挑。对我个人来说，Hexo 是平衡了功能、生态和上手难度之后最适合大多数人的方案。这篇文章后面全部以 Hexo 为例，但很多部署思路对 Hugo、VitePress 一样适用。

2.3 部署位置：GitHub Pages、VPS 还是对象存储

博客写好了要发布到网上，这步叫部署。静态博客的部署选择是整个链路里最灵活的一环，也是很多人容易纠结的地方。

第一个选项是 GitHub Pages，也就是 GitHub 提供的免费静态托管服务。它能和你的仓库联动，一推代码就自动更新页面。优点是不花钱、不用管服务器、全球有 CDN 加速。缺点是国内访问速度时快时慢，偶尔会被校验不通过，这是由网络链路决定的，需要你心里有数。第二个选项是自己买一台 VPS，装 Nginx 然后把文件传上去。优点是完全可控，可以用来挂博客之外的很多东西——比如私有网盘、在线笔记、甚至本地大模型的服务。缺点是每月要花钱，你要会一点 Linux 基础，还要处理备案的问题。第三个选项是对象存储加 CDN，比如阿里 OSS、腾讯 COS 这类。把生成好的静态文件传到存储桶里，开启静态网站托管，再套一层 CDN。优点是速度快、成本低、即使有大流量也不怕，缺点是纯静态托管没有 HTTPS 证书自动续期方便度一般，动手能力要求高一些。

我的建议是：前三个月用 GitHub Pages 起步，一分钱不花，专注写作。等你内容多了，对速度和稳定性有更高要求了，再切到 VPS 或者对象存储。我先按这个路线把完整流程走一遍，VPS 方案单独开一节讲。

3. 从零搭建本地写作环境：Node、Git 与 Hexo 初始化

3.1 安装前置依赖，这里有个容易翻车的版本问题

Hexo 依赖 Node.js 和 Git。Git 负责版本管理和部署推送，Node.js 负责跑 Hexo 本身。

Node.js 的安装有个细节值得注意：不要图省事去官网下载最新版。Hexo 对 Node 版本不是无脑兼容的，我自己实测过，Node 20 以上的版本在同一些老主题或者插件上偶尔会报错，而 Node 18 是当前兼容性最好的选择。下载地址直接搜“Node.js 长期支持版”，找 LTS 版本的下载就行。装完之后建议顺手装一个 nvm（node 版本管理器），以后要切换版本时会非常方便。

Git 的安装更简单，Windows 上一直点下一步就行。装完之后打开终端（Windows 上可以用 Git Bash），先验证一下环境：

node -v npm -v git --version

如果三个命令都能输出版本号，说明环境没问题。这里多说一句，Windows 用户遇到的第一个坑通常是终端路径问题——建议把所有项目目录都放在纯英文路径下，不要放桌面带中文的文件夹，否则后面 npm 安装依赖时会因为路径问题各种报错，这种问题排查起来非常折腾。

3.2 安装 Hexo 并初始化项目目录

环境就绪后，安装 Hexo 命令行工具：

npm install -g hexo-cli

然后在你想要存放博客的目录下初始化：

hexo init my-blog cd my-blog npm install

hexo init做的事情是拉取一套 Hexo 官方默认的站点模板，里面包含了博客最基本的目录结构。npm install则是把 Hexo 本身以及默认主题需要的依赖全部装好。这两步结束后，你的博客骨架就已经能跑了。

验证一下：

hexo server

终端会输出一个地址，通常是http://localhost:4000，浏览器打开它，你就能看到一个默认主题的博客页面。这个本地预览的命令后面会天天用到，Ctrl + C可以停掉服务。

3.3 目录结构拆解：每个目录是干什么的

初始化完成后，项目目录里有几个关键文件和文件夹，理解它们比背命令更重要：

• _config.yml：Hexo 的站点配置文件，博客名称、作者、URL 结构、部署信息都在这里，相当于博客的总控台。
• source/：存放源文件。你写的文章放在source/_posts/下，图片放在source/images/或对应文章目录里。
• themes/：存放主题。这个文件夹里的是实际生效的主题，每个主题有自己的_config.yml，相当于主题自己的独立配置。
• public/：hexo generate生成的静态文件输出目录。这个目录才是你真正部署到服务器的东西。本地预览时hexo server默认预览的也是它。
• package.json：依赖声明文件，记录了这个项目装了哪些 Node 包。

这里我要强调一个新手最常见的困惑：你写文章是写在source里的，改了之后要先hexo generate生成到public，别人看到的内容才会变。一些人改完文章发现线上没变化，就是因为忘了重新生成。

4. 写作流程与配置细节：从第一篇 Markdown 到本地预览

4.1 写文章的命令与 Front Matter 详解

写作是博客的核心。在 Hexo 里新建一篇文章的命令是：

hexo new "我的第一篇博客"

这条命令会在source/_posts/下生成一个名为我的第一篇博客.md的文件。文件顶部有 YAML 格式的 Front Matter，就是被三条横线包裹的那部分内容，长相类似：

--- title: 我的第一篇博客 date: 2025-11-20 14:30:00 tags: categories: ---

Front Matter 是控制文章元数据的关键。几个我会高频使用的字段：

• title：文章标题。如果不写，Hexo 默认用文件名当作标题。
• date：发布时间。它不止是展示用的，还直接决定文章在归档页面里的排列顺序。
• tags和categories：标签和分类。建议早期就建立好分类体系，比如“技术、随笔、资源推荐”，不然文章多了以后回顾整理会很痛苦。
• cover：封面图路径，部分主题支持，可以让列表页好看很多。
• updated：文章更新时间，填了之后可以让读者感知内容的时效性。

写文章就是直接在这个 Markdown 文件里写正文，语法上支持标准的 Markdown 和绝大部分的 HTML 标签。注意事项只有一个：Markdown 的标题建议从二级标题开始写，因为一级标题已经被文章标题占用了，否则层级逻辑会乱。

4.2 图片管理策略：本地存放还是图床

图片是博客内容质量的重要组成，但处理不好会带来持久的心智负担。我个人当前的策略是：图片统一放在source/images/2025/这样的目录结构下，按月份分文件夹。在文章里引用的时候写相对路径，比如：

![架构图](/images/2025/blog-deploy-architecture.png)

这样写的好处是图片跟着仓库走，随博客一起部署，不需要额外的图床账号，绝不担心外链失效。缺点也有：仓库体积会变大，构建时间会变长，如果图片很多的话，Git 仓库可能会变得很臃肿。

如果你拍的是手机照片、录屏这类体积大的图片，强烈建议先压缩再放上来。我常用squoosh这个免费在线工具，或者本地命令行工具ImageMagick。一张 5MB 的手机照片压到 200KB 以内对于网页展示完全够用，肉眼几乎看不出区别，但加载速度的天壤之别是你和读者都能感受到的。

图床方案（把图片放在第三方对象存储里）适合流量很大的站点，或者你特别在意仓库体积。代价是你要多维护一层资源，而且如果图床服务挂了，你所有文章里的图就全挂了。我见过不少博主经历过这种惨剧，所以后来老老实实回到本地存放。

4.3 本地预览与写作节奏

写作时我习惯保持一个终端窗口跑着hexo server，浏览器开着localhost:4000，每写一段就切过去刷新看一眼渲染效果。Markdown 编辑器里看着排版没问题，和实际渲染出来的效果往往是两回事，特别是列表嵌套、代码块换行、图片尺寸这些，只有在浏览器里才能看到真实效果。

hexo server有一个很好用的特性：当你修改了源文件并保存，它会自动侦测变化并重新生成，你只需要刷新浏览器就行，不需要重新执行命令。所以写文章时保存之后立刻刷新页面，就能看到更新。

5. 把博客发布到公网：GitHub Pages 与 Actions 自动部署

5.1 为什么选择 GitHub Pages 作为第一种线上方案

我上一节解释了 GitHub Pages 免费、无需服务器、有 CDN 等优点。再补充一点重要的：它和 Git 天然融合，部署流程就是推送代码，这个心智模型足够简单，能让刚接触博客的人把精力省下来，投入到写作本身。

GitHub Pages 也不只是托管静态文件的“死存放”，它在全球有加速节点，页面加载速度一般优于普通单机 VPS。对于一些访问量不大的个人博客，它扛住几千甚至几万 PV 完全没问题。

5.2 创建仓库并配置部署信息

在 GitHub 上创建一个仓库，名字有讲究：如果你想通过https://用户名.github.io这个域名访问，那么仓库名必须是用户名.github.io，连用户名的大小写都不用在意。比如我的用户名是wangkai，仓库名就是wangkai.github.io。

然后修改博客根目录下的_config.yml，找到deploy相关配置改成：

# 部署配置 deploy: type: git repo: https://github.com/你的用户名/你的用户名.github.io.git branch: main

这里type: git指定使用 Git 方式部署，repo是仓库地址，branch是分支名。GitHub 默认分支现在是main，如果填成master会一直推不上，这是很常见的问题。

接着初始化 Git 并推送：

git init git add . git commit -m "first commit" git remote add origin 你的仓库地址 git branch -M main git push -u origin main

这步完成之后，你的源代码（包括 Markdown 文件和主题）已经被推送到 GitHub 了。但注意，这只推送了源码，还没发布静态页面。接下来要配置自动部署。

5.3 用 GitHub Actions 实现一键部署

GitHub Actions 是 GitHub 自带的 CI/CD 功能，简单理解就是在特定触发条件下自动执行你预设的脚本。部署博客的自动化流程通常是：每当源代码推送到仓库，GitHub 自动帮你在云端运行hexo generate，然后把生成的public/推送到某个分支上，GitHub Pages 再从那个分支发布。

具体做法是：在项目目录下创建.github/workflows/deploy.yml文件，内容参考：

name: Deploy Blog on: push: branches: - main # 源码推送目标分支 jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: 检出代码 uses: actions/checkout@v3 - name: 安装 Node.js uses: actions/setup-node@v3 with: node-version: 18 # 和本地保持一致 - name: 安装依赖 run: npm install - name: 生成静态文件 run: npx hexo generate - name: 部署到 GitHub Pages uses: peaceiris/actions-gh-pages@v3 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./public

把这个文件推送上去之后，GitHub 会自动运行流水线。之后你每次写的文章都只需要这两条命令就能上线：

git add . git commit -m "发布新文章" git push

如果 Actions 运行正常，等一两分钟，访问https://用户名.github.io就能看到博客上线了。注意第一次访问可能延迟一两分钟，GitHub 的构建和发布有缓存，这是正常的。

这套流程熟练以后，写博客的体验会非常流畅——本地写，预览，推送，发布。没有了“上传服务器”“登录面板”“点按钮部署”这些重复动作，文章更新的频率会决定性地变高。

5.4 自定义域名与 HTTPS 证书

默认的用户名.github.io域名虽然能用，但从个人品牌角度看，还是建议花几十块钱买个自己的域名。注册域名的平台很多，选一个信任的即可，费用一般一年五六十块。

购买域名后，在域名服务商的 DNS 设置里添加一条 CNAME 记录，指向用户名.github.io。然后在博客的source/目录下新建一个文件名为CNAME的文件，内容只填你的域名，一行，没有别的字符：

blog.example.com

为什么要在仓库里放这个文件：GitHub Pages 会读取这个文件并把你的自定义域名和这个仓库绑定，如果缺了它，每次重新部署之后自定义域名都会被重置掉，访问就跳回默认域名了。把CNAME文件放在源代码里，意味着每次部署自动带上它，再也不用担心重置问题。

关于 HTTPS 证书，GitHub Pages 为自定义域名自动签发了证书，不需要你做任何事。配置好 CNAME 之后在 GitHub Pages 设置页面里打开强制 HTTPS 功能，等它签发完成即可。这个过程少则十分钟，多则几小时，哪都不需要动，刷几下页面就能看到小锁标志出现。

6. 进阶部署：VPS 与 Docker 方案、CDN 加速

6.1 什么时候该从 GitHub Pages 迁移到 VPS

GitHub Pages 免费稳定，但有两件事它做不了：一是响应式不够快——我说的是 TTFB（首字节时间），国内访问时链路绕路导致首屏延迟有时候能到好几秒；二是不能跑任何服务端程序，不能挂在线工具、API、网盘这类东西。

当你开始在意首屏速度，或者想在博客之外拓展点别的功能时，就该考虑 VPS 了。VPS 就是一台远程的 Linux 电脑，你有 root 权限，想装什么装什么。

我建议选购配置的思路：个人博客流量不大，1 核 1G 内存的机器完全够用。但你如果想在上面跑容器、数据库之类，建议 2 核 2G 起步，价格一般在每月三四十块。地区选择上，如果你主要读者在国内，优先选香港或就近地区的线路；如果你写完不管读者在哪，那就随意了。

6.2 用 Docker 部署 Nginx 托管静态文件

为什么要用 Docker？因为 Docker 能把你部署的整个运行环境打包起来，换机器、迁移、升级都只需要一条命令，不用重新一步步装软件、配环境。

安装 Docker 之后，在服务器上创建一个目录，比如/opt/blog，把本地hexo generate生成的public/目录整个传上去：

scp -r public/* root@你的服务器IP:/opt/blog/

然后在服务器上运行：

docker run -d \ --name blog \ -p 80:80 \ -v /opt/blog:/usr/share/nginx/html:ro \ nginx:stable-alpine

这条命令的含义是：以后台方式运行一个名为 blog 的容器，把服务器的 80 端口映射到容器内部 Nginx 的 80 端口，把/opt/blog目录挂载到 Nginx 的静态目录里，只读模式。镜像用的是nginx:stable-alpine，体积小、安全性高。

跑起来之后，访问服务器 IP 就能看到博客首页。如果你还没备案域名，直接访问 IP 是可以的；要绑定域名就要解析域名到服务器 IP，然后反向代理层或者 Nginx 配置里把该域名指到这个站点。这个过程不建议新手一上来就搞，最好是 GitHub Pages 跑了几个月、文章积累了一批以后再折腾。

6.3 评论区、统计与搜索：静态博客的三件套

静态博客没有后端，所以评论区、统计、搜索这些动态功能都需要借助第三方服务。评论区我推荐giscus或utterances，原理都是利用 GitHub Issues 来存储评论，访客不需要注册你站点的账号，直接用 GitHub 账号登录就能评论，部署也很简单——在篇模板里加一段官方脚本即可。

统计工具方面选择比较多，不蒜子是国内比较轻量的方案，直接嵌入一行脚本就能统计 PV 和 UV，虽然数据准确性一般，但趋势参考够用。搜索引擎收录的话，可以让主题支持生成sitemap.xml，然后在各大搜索引擎的站长平台里提交站点，这件事尽早做，因为 Google 和百度收录新站都需要时间。

6.4 可选优化：CDN 加速静态资源

CDN 的原理是在各地部署缓存节点，让访客就近获取数据，从而提高访问速度。国内主流的 CDN 服务商都提供了静态加速产品，使用流程基本一致：添加域名，把源站设置为 VPS 地址，配置缓存规则，释放 CNAME 回源域名到 CDN 节点。

CDN 对博客加速效果好的重资产主要是图片、CSS、JS 这类静态文件。我的经验是图片缓存设成 7 天，CSS/JS 设成 1 天，这样发布的文章能在当天看到更新，之后访问就走缓存速度很快，也不会有“改了不生效”的烦恼。站点的 HTML 文件本身不建议做长缓存，因为博客更新频繁，缓存过期时间设成 0 或者 60 秒比较稳妥，保证读者能看到你的最新文章。

7. 主题选择与个性化调优

7.1 选主题的标准和我踩过的坑

Hexo 主题数量非常多，但质量参差不齐。我的选主题标准有三个：维护活跃度、文档完整度、可定制性。维护活跃度看仓库的最近提交时间，超过一年没更新的直接跳过，因为这种主题大概率跟不上 Hexo 主版本更新，后续用起来全是兼容问题。文档完整度看主题的 README 是否覆盖了安装、配置、启用三个完整环节。可定制性看它是不是有_config.yml提供足够多配置项，改布局、加导航、换颜色这种需求能不能不碰代码就实现。

我最早踩过一个坑：选了一个很好看但作者已弃坑的主题，当时为了适配新版本 Hexo 自己啃了一礼拜模板源码，才把构建错误修好。后来我学乖了，直接用社区长期维护的大众主题，比如NexT和Butterfly，它们有庞大的用户群和文档，几乎不会遇到无人解答的困境。NexT 偏简洁、加载速度快，适合技术笔记风格；Butterfly 样式更现代、卡片式布局更接近主流审美，适合图文类内容。我目前用的就是 Butterfly。

7.2 主题层面的必备配置

安装主题的常规流程是把主题仓库克隆到themes/目录，然后在站点_config.yml中把theme字段改成主题名。之后真正花时间的地方是主题自己的配置文件。

必改的配置我总结了一下：

• 站点 logo 和 favicon：博客的视觉门面，不改的话会一直显示默认图标，专业感少一半。
• 导航菜单：首页、归档、标签、分类页这几个基础页面建议都配上。
• 侧边栏：如果你的主题支持，可以把最近文章、标签云、友链都放上去。
• 代码块主题：技术博客代码展示频率最高，建议选一个深色系的高亮主题，比如darcula或github-dark，默认配色通常或者太浅或者对比度不够，影响阅读。
• 社交链接：GitHub、邮件、推特之类，放上来能增加博主触达面。

要记住，主题配置文件的修改和站点配置文件修改是两个不同的_config.yml，别改错位置了。很多人折腾了半天没效果，结果发现自己改的是站点配置文件而主题相关设置全在主题的配置文件里。

7.3 常见自定义需求的做法

改字体、改主色调、加友链、加打赏按钮这类操作，不同主题的入口不一样，但通用思路是：先看主题文档的“自定义”章节，找不到就搜索主题名加关键词。不要一上来就动模板源码，改完主题一更新你的修改就丢了。

我建议尽量用主题提供的外部配置项来做个性化，少改源码。主题更新版本时远比你的想象频繁，源码改动多了，更新主题会变成一项痛苦的合并战。

8. 日常运维与踩坑实录

8.1 内容备份的分层策略

很多人博客搭建好之后，最大的风险就是写了大半年、文章全在本地硬盘上，结果硬盘一挂全没了。Git 仓库本身就是一个天然的备份体系，但大多数人只把博客源码推到了 GitHub，source目录里有什么就备份了什么，这很好。

如果你想更保险，建议再加一层：把整个博客目录（不包括node_modules和public，它们是生成产物）用网盘同步工具备份一次，同时这个仓库本身也推一份到 GitHub 的私有仓库。这样本地、远程都有副本，丢了任何一个都能完整恢复。

数据库类动态博客如果需要备份，一般是用定期任务导出数据库文件然后异地存储。静态博客在这方面省心太多了，写文章本身就是备份，这是它又一个大优势。

8.2 高频故障排查表

部署和写作过程中我遇到过大量问题，下面整理成一个速查表，按频率排序：

8.3 我踩过的三个最痛的坑

第一个坑：域名备案问题。最开始我买了个国内 VPS 搭博客，解析完域名发现需要备案，流程走了一周多，期间网站完全无法通过域名访问。后来我换了思路，用海外 VPS 解决了这个问题，省了很多事。如果你要用国内节点，务必提前把备案流程启动，不要等到解析完成才发现。

第二个坑：图片仓库膨胀。前期写文章时把很多截图原图直接丢进博客仓库，几个月后仓库体积到了几百 MB，克隆一次要等好久。治本的方法就是建立写文章时遵守一个流程：截图后先压缩再放进来。细节我前面写过了，别偷懒，压一遍再传。

第三个坑：主题更新覆盖修改。有一次主题更新版本后我早先手动改过的模板全被覆盖了，页面样式全乱。那次之后我下决心只做配置项改动，同盟类的功能需求尽量通过配置去达成。这算是“少改源码”这个教训的代价版。

8.4 写作流程的最后一公里：检查清单

博客上线之后，我每篇文章发布前都会过一遍简易清单，能省掉很多后知后觉的尴尬：

• 标题和 Front Matter 信息完整，无残留的默认值。
• 全文一级标题不超过一个，结构层级合理。
• 图片已压缩，路径正确，本地预览全部能加载。
• 标签和分类命名统一，没有临时的随意标签。
• 代码块标注了语言类型，缩进正常，没有多余空行。
• 在本地浏览器模拟手机宽度看一眼排版，避免手机上阅读体验崩坏。
• 推送前运行一次npx hexo clean && npx hexo generate，确认构建无报错。

这个清单看起来繁琐，实际花不了两分钟，但它能把很多“发布之后才发现问题”的尴尬提前杀死。

9. 一点个人经验，写在最后

博客搭建从零到部署这条链路，我前前后后走了三遍，踩过的坑比写出来的多得多。现在回头看，最核心的心得就一句话：工具要服务于写作，而不是反过来。

很多人会花大量时间在选主题、改样式、配插件上，一篇文章没写就折腾了一周。我见过最夸张的博主，博客框架搭了三个月，域名买了好几个，最后连一篇像样的文章都没发出来，原因就是他一直在“准备工作”。而真正持续写的人，往往一开始用的是最简单的方案——可能就是一个默认主题、没有任何插件、域名都没买，先把第一篇文章发了再说。等写了几十篇之后，他对自己的需求和读者也有了更清晰的认识，再来做优化和设计，每一步调整都有明确目标，不再盲目。

如果你今天刚看完这篇文章，想动手试一试，那我的建议是：按文中的流程把 GitHub Pages 那条路走通，然后立刻写一篇文章发出去。别看教程、别改主题、别想着优化什么，先让第一篇文章上线。从“搭建博客”到“拥有一个博客”，差的不是教程，是那一篇真正被发布出去的文字。

之后每当你遇到问题，回到这篇文章的排查表里翻一翻——大部分问题这里都有答案。等你把写作变成了习惯，再回来看第 6 节聊的 VPS 和 Docker，那时候你会发现之前觉得很难的东西，已经在不知不觉中变成了常识。