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 版本的下载就行。装完之后建议顺手装一个 nvmnode 版本管理器以后要切换版本时会非常方便。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 installhexo init做的事情是拉取一套 Hexo 官方默认的站点模板里面包含了博客最基本的目录结构。npm install则是把 Hexo 本身以及默认主题需要的依赖全部装好。这两步结束后你的博客骨架就已经能跑了。验证一下hexo server终端会输出一个地址通常是http://localhost:4000浏览器打开它你就能看到一个默认主题的博客页面。这个本地预览的命令后面会天天用到Ctrl C可以停掉服务。3.3 目录结构拆解每个目录是干什么的初始化完成后项目目录里有几个关键文件和文件夹理解它们比背命令更重要_config.ymlHexo 的站点配置文件博客名称、作者、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/这样的目录结构下按月份分文件夹。在文章里引用的时候写相对路径比如这样写的好处是图片跟着仓库走随博客一起部署不需要额外的图床账号绝不担心外链失效。缺点也有仓库体积会变大构建时间会变长如果图片很多的话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/checkoutv3 - name: 安装 Node.js uses: actions/setup-nodev3 with: node-version: 18 # 和本地保持一致 - name: 安装依赖 run: npm install - name: 生成静态文件 run: npx hexo generate - name: 部署到 GitHub Pages uses: peaceiris/actions-gh-pagesv3 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 迁移到 VPSGitHub 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 仓库本身就是一个天然的备份体系但大多数人只把博客源码推到了 GitHubsource目录里有什么就备份了什么这很好。如果你想更保险建议再加一层把整个博客目录不包括node_modules和public它们是生成产物用网盘同步工具备份一次同时这个仓库本身也推一份到 GitHub 的私有仓库。这样本地、远程都有副本丢了任何一个都能完整恢复。数据库类动态博客如果需要备份一般是用定期任务导出数据库文件然后异地存储。静态博客在这方面省心太多了写文章本身就是备份这是它又一个大优势。8.2 高频故障排查表部署和写作过程中我遇到过大量问题下面整理成一个速查表按频率排序现象可能原因解决方案hexo server启动后页面打不开4000 端口被占用hexo server -p 5000换端口或找到占用进程结束掉推送到 GitHub 后线上没更新Actions 失败或还在运行打开仓库的 Actions 标签页看日志确认npm install步骤用的 Node 版本和本地一致部署成功后图片加载 404图片路径写错或未重新生成在本地hexo server下先确认图片能显示注意文件和目录命名不要带中文自定义域名访问跳回用户名.github.ioCNAME文件丢失把CNAME文件放回source/根目录并重新部署别放在public/或themes/下修改_config.yml后没变化改了错误的配置文件确认是站点根目录的_config.yml还是themes/主题名/_config.yml文章发布后日期显示不对Front Matter 中date格式错误或未写检查格式形如2025-11-20 14:30:00时间区设置是否合理GitHub Pages 部署时提示权限错误默认GITHUB_TOKEN权限不足在仓库 Settings Actions General 中把 Workflow permissions 改成读写权限端口 80 被占用导致 VPS 启动失败服务器上有其他 Web 服务在跑改用 8080 端口先验证容器或者用sudo netstat -tlnp找出占用进程8.3 我踩过的三个最痛的坑第一个坑域名备案问题。最开始我买了个国内 VPS 搭博客解析完域名发现需要备案流程走了一周多期间网站完全无法通过域名访问。后来我换了思路用海外 VPS 解决了这个问题省了很多事。如果你要用国内节点务必提前把备案流程启动不要等到解析完成才发现。第二个坑图片仓库膨胀。前期写文章时把很多截图原图直接丢进博客仓库几个月后仓库体积到了几百 MB克隆一次要等好久。治本的方法就是建立写文章时遵守一个流程截图后先压缩再放进来。细节我前面写过了别偷懒压一遍再传。第三个坑主题更新覆盖修改。有一次主题更新版本后我早先手动改过的模板全被覆盖了页面样式全乱。那次之后我下决心只做配置项改动同盟类的功能需求尽量通过配置去达成。这算是“少改源码”这个教训的代价版。8.4 写作流程的最后一公里检查清单博客上线之后我每篇文章发布前都会过一遍简易清单能省掉很多后知后觉的尴尬标题和 Front Matter 信息完整无残留的默认值。全文一级标题不超过一个结构层级合理。图片已压缩路径正确本地预览全部能加载。标签和分类命名统一没有临时的随意标签。代码块标注了语言类型缩进正常没有多余空行。在本地浏览器模拟手机宽度看一眼排版避免手机上阅读体验崩坏。推送前运行一次npx hexo clean npx hexo generate确认构建无报错。这个清单看起来繁琐实际花不了两分钟但它能把很多“发布之后才发现问题”的尴尬提前杀死。9. 一点个人经验写在最后博客搭建从零到部署这条链路我前前后后走了三遍踩过的坑比写出来的多得多。现在回头看最核心的心得就一句话工具要服务于写作而不是反过来。很多人会花大量时间在选主题、改样式、配插件上一篇文章没写就折腾了一周。我见过最夸张的博主博客框架搭了三个月域名买了好几个最后连一篇像样的文章都没发出来原因就是他一直在“准备工作”。而真正持续写的人往往一开始用的是最简单的方案——可能就是一个默认主题、没有任何插件、域名都没买先把第一篇文章发了再说。等写了几十篇之后他对自己的需求和读者也有了更清晰的认识再来做优化和设计每一步调整都有明确目标不再盲目。如果你今天刚看完这篇文章想动手试一试那我的建议是按文中的流程把 GitHub Pages 那条路走通然后立刻写一篇文章发出去。别看教程、别改主题、别想着优化什么先让第一篇文章上线。从“搭建博客”到“拥有一个博客”差的不是教程是那一篇真正被发布出去的文字。之后每当你遇到问题回到这篇文章的排查表里翻一翻——大部分问题这里都有答案。等你把写作变成了习惯再回来看第 6 节聊的 VPS 和 Docker那时候你会发现之前觉得很难的东西已经在不知不觉中变成了常识。