手里那几个博客方案来回折腾了半个月最后留下的还是这套本地写好 Markdown一条命令生成整站静态页面往服务器或 Pages 服务上一扔完事。从域名解析到 HTTPS 自动续期坑都踩过一遍之后我决定把整套流程拆开写明白。这篇「博客搭建全攻略从零到部署」不吹工具、不堆术语只解决一个核心问题怎么用最短的路径把你的第一个博客安全、稳定地跑起来并且后续想加功能时不会被自己搭的架子卡住。这篇内容适合几类人完全没接触过命令行的小白、在 WordPress 和静态博客之间纠结的选择困难症、以及已经把博客搭起来但部署总出问题的进阶玩家。我尽量按「为什么这么做」而不是「照着抄就行」的逻辑来讲因为只有理解了每一步在解决什么问题之后遇到报错才不至于全靠百度。1. 方案选型为什么我说静态博客是大多数人的最优解1.1 动态博客和静态博客差的不是技术而是精力你可能听说过 WordPress、Typecho、Halo 这些动态博客系统。它们的特点是后台界面操作、数据库存文章、每次访问页面时由服务端实时生成 HTML。听起来很美好但对一个只是想记录和输出的个人博客来说动态方案有三个我后来才意识到的隐性成本。第一是服务器维护。PHP 环境、MySQL、对象存储、安全补丁哪一样都要花时间。我见过不少人博客搭好之后三个月没登录再上去发现后台被爆破、网站被挂马。第二是备份成本。数据库里的每一篇文章都得导出备份一个不小心就是全部清零。第三是访问速度。个人博客本来流量不大却要为一篇 2KB 的文章付出整个服务端渲染的开销。静态博客把这些问题全干掉了。我用 Hexo 写文章本地编译生成的是纯 HTML、CSS、JS 文件存放和传输都不需要任何动态处理托管在 GitHub Pages、腾讯云静态托管或者自己的 Nginx 上都能跑。没有了数据库备份就是复制文件夹没有了后端程序安全问题直接减少一个数量级。代价就是发文章必须走命令行但对程序员来说这根本不是代价反而是一种顺手的工作流。1.2 主流静态博客框架横向对比Hexo、Hugo、VitePress静态博客生成器有不少大家常年纠结的就是 Hexo、Hugo 和近年火起来的 VitePress。我三套都用过一段时间直接说结论。Hexo 基于 Node.js生态最大主题数量多得夸张中文社区一个人问问题底下好几个人回答。上手速度在三者里最舒适npm 装上hexo init 一下默认就有一个能看的博客。Hugo 基于 Go生成速度是真的快几千篇文章也是秒级编译。缺点是模板语法是 Go 的主题数量不如 Hexo 多想改起来门槛更高。VitePress 本来是文档站工具因为 Vue 生态的加持和漂亮的默认主题被一些博客玩家拿来当博客用。它对 Markdown 的支持非常好Vue 组件随意嵌入但严格来说它定位不是博客分类、标签、归档这些博客经典功能需要自己折腾插件或组件。我给新手建议很简单选 Hexo。原因不是 Hugo 和 VitePress 不好而是 Hexo 在「我要快速拥有一个完整博客」这件事上默认功能最齐全踩坑参考资料最多。等你写满五十篇文章对底层原理有了感觉再考虑要不要换框架也不迟。博客内容永远比博客系统本身重要不要在搭建阶段纠结太久。1.3 整条搭建链路到底要经过哪些环节在动手之前先把整条路线看清楚后边每一步就不会迷茫。从零到部署拆开就是七个环节。第一个环节是环境准备本机装好 Node.js 和 Git这是 Hexo 运行的两个基础工具。第二个环节是初始化项目用 hexo init 生成博客骨架装好默认依赖。第三个环节是基础配置编辑 _config.yml 里的站点名称、作者、语言这些全局信息。第四个环节是本地写作和预览用 Markdown 写文章运行 hexo s 在浏览器里实时查看效果。第五个环节是主题美化选择一个喜欢的主题做个性化调整。第六个环节是生成静态文件hexo g 把 Markdown 渲染成 HTML 输出到 public 目录。第七个环节是部署上线把 public 目录里的文件推送到服务器或托管平台并绑定你自己的域名。很多教程把前两步揉在一起讲导致新手经常分不清你改的到底是哪个文件、生成的文件在哪里。我在下面会用完整篇幅把每一步掰开所有命令都给出可复制的版本。2. 环境准备与 Hexo 本地初始化手把手跑通最小链路2.1 装好 Node.js 和 Git并验证安装是否成功Hexo 依赖 Node.js 运行依赖 Git 做主题安装和部署推送。两个工具是整条链路的底座装错版本后面会很痛苦。Node.js 直接去官网nodejs.org下载 LTS 版本即可不要追新LTS 代表长期维护版本稳定性优先。Windows 用户建议用安装包傻瓜安装macOS 用户可以 brew install nodeLinux 用户用包管理器。装完之后打开终端Windows 用 PowerShell 或 CMDmacOS 用 Terminal依次执行两条命令检查版本node -v npm -v正常情况下会输出两个版本号比如 v20.11.1 和 10.2.4。如果提示「command not found」或者「无法识别」说明环境变量没配好Windows 用户重新运行安装包选择修复安装一般能解决。Git 同理Windows 装 Git for WindowsmacOS 可以用 brew install git。装完执行 git --version 确认输出版本号。Git 还需要配置提交者信息因为部署到 GitHub 时要用到它git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有个小坑想提醒一下npm 在下载依赖时默认走官方源在国内网络环境下偶尔会慢到让人怀疑人生。如果你有这种困扰可以换成国内的 npmmirror 镜像源npm config set registry https://registry.npmmirror.com这样后续安装 Hexo 和所有插件都会快很多。2.2 全局安装 Hexo 脚手架并初始化项目环境验证完毕接下来安装 Hexo 的命令行工具npm install -g hexo-cli这个 -g 代表全局安装装完之后终端里就多了一个 hexo 命令。建议等安装输出结束之后执行 hexo version 看一眼版本号确认安装成功。然后找一个你打算放博客代码的目录比如新建一个 site 文件夹进去执行初始化命令hexo init blog cd blog npm installhexo init 会从 GitHub 拉取 Hexo 的基础模板包含默认配置、主题、文章示例。npm install 是根据模板里的 package.json 安装所有依赖。整个过程中如果有红色报错绝大多数是网络问题重新执行一次基本就好。初始化完成后可以先启动本地预览验证整个链路是否打通hexo s终端会打印一行类似 INFO Hexo is running at http://localhost:4000 。浏览器打开这个地址看到一个默认主题的博客页面就说明你的 Hexo 已经能跑了。这一步我强烈建议不要跳过它能确认绝大多数环境问题在最早期暴露出来而不是等写了几篇文章之后才发现框架本身没起来。2.3 博客目录结构逐项拆解哪个文件夹放了什么初始化完毕第一件事不是急着写文章而是搞懂这个项目里每个目录是干什么的。我用我自己的博客目录做示例结构大致如下blog/ ├── _config.yml # Hexo 主配置文件 ├── package.json # 项目依赖与脚本 ├── node_modules/ # 安装的依赖包 ├── scaffolds/ # 文章模板 ├── source/ # 博客源文件写的文章都在这 │ ├── _posts/ # Markdown 文章存放处 │ └── about/ # 「关于」页面等 └── themes/ # 主题目录最重要的就是 _config.yml它是 Hexo 的全局配置文件站点标题、URL、语言、主题名全在这里后面我会专门拆开讲。source/_posts 是你的文章仓库所有 .md 文件写在这里。scaffolds 文件夹控制的是当你执行 hexo new post 时生成的默认内容模板可以自定义成自己想要的样子。themes 文件夹放主题一个主题就是一个子目录。这里面新手最容易懵的是 public 文件夹。执行 hexo generate简写 hexo g之后Hexo 会把 source 里的 Markdown 渲染成 HTML全部输出到 public 目录。这个目录才是你要部署的东西本地写文章时它可能会生成很多次不值得编辑一般也不会纳入 Git 管理。理解了这个关系后面部署环节你就知道为什么推的是 public 而不是整个项目。2.4 主配置文件 _config.yml 必改字段清单_config.yml 是 YAML 格式重点不是格式是那几个字段直接决定你博客的门面信息。打开文件我会建议你优先改这几项title: 我的博客 subtitle: 记录学习与生活 description: 个人技术博客分享编程与运维经验 keywords: 博客,技术,编程 author: 你的名字 language: zh-CN timezone: Asia/Shanghai url: https://yourdomain.comtitle 是站点标题会出现在浏览器标签页和首页顶部。subtitle 是副标题很多主题会在标题旁边或下面展示它建议写得简短有力。author 会在文章底部和 RSS 源里出现。language 决定主题找哪套语言文件主题支持中文的话填 zh-CN。timezone 设成 Asia/Shanghai。url 是你博客最终访问的域名本地预览阶段可以随意填但部署上线前一定要改成真实地址因为很多主题和插件会用 url 生成站内链接。需要提醒的是_config.yml 对缩进极其敏感YAML 靠空格区分层级不要用 Tab。凡是「配置改了没生效」的问题第一反应就是去检查这个文件有没有语法问题。改完保存后需要重启 hexo s 才会生效。2.5 用模板创建第一篇文章认识 front-matter跑通最小链路之后可以尝试创建一篇文章看看效果hexo new post 我的第一篇博客这条命令会在 source/_posts 下生成一个「我的第一篇博客.md」文件打开看内容是这样的--- title: 我的第一篇博客 date: 2024-12-21 15:42:00 tags: ---中间两个三根横线包围的区域叫 front-matter是这篇文章的元数据。title 是文章标题date 是发布时间tags 是标签。front-matter 还可以写 categories分类、updated更新时间、comments是否允许评论等字段。例如我想加一个分类和两个标签就会改成这样--- title: 我的第一篇博客 date: 2024-12-21 15:42:00 tags: - Hexo - 博客搭建 categories: 技术分享 ---写完正文保存浏览器打开 localhost:4000 就能看到新文章。这里有个细节Hexo 默认文章页 URL 会带日期如果后续改了文章文件名URL 也会变影响老链接。很多人会引入 hexo-abbrlink 插件用固定 ID 做链接我建议在文章量还少的时候尽早做这个决定等积累了几十篇再改链接是场灾难。3. 主题选择与站点美化让博客看起来像个作品3.1 主题怎么挑不要沉迷于换主题Hexo 的主题站点在官方仓库里列了一大批风格覆盖极简、卡片、杂志、技术文档等方向。挑选原则我只提一条默认观感你看着舒服、文档完善、最近一年还有更新。技术圈比较主流的几款有 Next经典老牌、Fluid优雅极简、Matery功能丰富、Icarus模块化。我自己用的是 Fluid理由是它对多设备适配做得好移动端看文章很舒服而且配置项文档化程度高改起来不费劲。安装主题有两种方式。一种是用 Git 将主题仓库克隆到 themes 目录下git clone https://github.com/theme-next/hexo-theme-next.git themes/next然后在 _config.yml 里把 theme 字段的值改成主题目录名theme: next另一种方式是 npm 安装主题包这种方式升级更方便但不是所有主题都支持。每个主题一般都有自己的文档说明照着做就行。装完之后执行 hexo clean hexo g hexo s本地预览看看效果。hexo clean 的作用是清掉历史生成的 public 目录避免旧文件残留导致样式错乱。每当你换了主题或者改了较大配置都建议先 clean 再重新生成这是很多灵异问题的标准解法。3.2 主题的独立配置别再往主配置里堆东西不少新手把主题所有参数都写进 Hexo 的主 _config.yml结果换主题时配置全乱。正确的逻辑是站点全局信息标题、作者、语言放主 _config.yml主题外观和布局参数颜色、侧栏、菜单、CDN放主题自己的 _config.yml。主题配置文件在 themes/主题名/_config.yml。以 Fluid 为例里面可以设置 navbar 菜单、页面宽度、文章摘要长度、是否开启 toc 目录、代码高亮主题、评论系统、SEO 等参数。改完同样需要 hexo clean hexo g 重新生成才有变化。这里我特别提一下菜单导航。常见配置就是四个页面首页、归档、分类、标签。Fluid 这类主题可能还需要你手动创建页面hexo new page tags hexo new page categories执行完在 source 目录下会生成对应的文件夹和 index.md。你需要打开这个 md 文件在 front-matter 里加一个 type 字段例如--- title: 标签 date: 2024-12-21 16:00:00 type: tags ---这样主题才知道这个页面是做什么用的而不是当普通文章去渲染。每种主题的 type 命名略有不同以你选的主题文档为准。3.3 博客必备三件套评论、搜索、站点统计博客跑起来之后最想加的往往是评论功能。因为有思考的读者需要出入口评论区是交流的核心阵地。常见的方案有 giscus基于 GitHub Discussions、Waline自部署、支持匿名评论、Disqus国外老牌但国内访问体验一般等。我个人推荐 giscus原因是它产出的评论直接成为 GitHub Discussions 里的 Issue数据完全归自己不需要单独部署服务稳定性高。配置过程大致是先在 GitHub 上安装 giscus App、选择仓库、开启 Discussions然后到 giscus 官网生成一段配置代码把里面的>categories: - 技术 - 部署创建归档页、标签页的方式前面已经讲过了。开好这些页面之后建议顺手把主题里的 listing 页面文章列表的分页配置调一下比如每页 10 篇避免一页渲染几十上百篇文章拖慢速度。4. 从本地到线上部署到 Pages 服务的完整流程4.1 GitHub Pages 部署五步搞定静态托管部署方式里最省心的就是 GitHub Pages它专门用来托管静态站点不收费、支持自定义域名、自带 HTTPS。把 Hexo 生成的 public 目录推到 GitHub 仓库里开启 Pages 功能就完成了。首先在 GitHub 上创建一个仓库仓库名建议是你的用户名.github.io。因为这个名字的仓库会被自动识别为 Pages 项目。仓库创建好之后在本地博客目录里安装部署插件npm install hexo-deployer-git --save然后修改主 _config.yml找到 deploy 相关配置加上deploy: type: git repo: https://github.com/你的用户名/你的用户名.github.io.git branch: main最后执行hexo clean hexo g hexo dhexo d 是 hexo deploy 的简写作用是将 public 目录内容强制推送到指定仓库的 main 分支。第一次执行时可能会出现认证失败需要在 GitHub 创建个人访问令牌Personal Access Token把令牌作为密码输入即可。令牌的创建路径是 GitHub 头像 → Settings → Developer settings → Personal access tokens → Tokens (classic)勾选 repo 权限后生成。把令牌保存在本地密码管理器里今后部署会频繁用到。部署完成后浏览器打开https://你的用户名.github.io看到和本地预览一模一样的页面说明第一次部署成功。4.2 用 Gitee Pages 或腾讯云/阿里云静态托管弥补访问体验GitHub Pages 功能全面但对国内访客来说加载速度不一定理想。我自己部署时遇到过几次部署成功但访问特别慢的情况后面干脆做了两手准备GitHub Pages 作为主站同时再部署一份到国内托管平台。Gitee Pages 是码云的静态托管服务绑定自己的仓库后可以把 public 目录内容发布到 gitee.io 域名上。流程和 GitHub Pages 类似创建一个开源仓库把 public 内容推上去仓库服务里找到 Gitee Pages 服务选择部署分支点击启动即可。腾讯云静态托管、阿里云 OSS 静态网站这两种方案同样适合国内访问而且可以绑定备案过的域名。它们比 Gitee Pages 稳定性更好Gitee Pages 曾经有过需要人工审核才能部署的经历体验不算完美。如果不想动国内平台也可以给自己 GitHub Pages 套一层 CDN 加速例如 Cloudflare把自定义域名的 DNS 解析交给 CDN访客走 CDN 节点会快不少。CDN 本身是纯技术话题配置也不复杂值得花半天时间研究。4.3 自定义域名与 HTTPS 配置的细节博客肯定要有自己的域名xxxx.github.io当长期博客地址多少有点寒酸。域名购买渠道没有特别讲究阿里云、腾讯云、Cloudflare 都可以价格几十块一年。关键在于 DNS 解析配置。如果你的主托管是 GitHub Pages需要到 DNS 服务商处添加一条 A 记录指向 GitHub Pages 的服务器 IP或者添加一条 CNAME 记录指向你的用户名.github.io。同时需要在博客的 source 目录下创建一个没有扩展名的 CNAME 文件里面写一行你的域名例如blog.example.com这个 CNAME 文件会被一并部署到 GitHub确保 GitHub 知道该域名对应的是哪个仓库。很多人漏了这一步导致域名解析到了仓库但访问时 404。HTTPS 证书方面GitHub Pages 会自动为自定义域名申请和续期 SSL 证书配置好 CNAME 后等待一两天即可。国内平台一般也内置免费证书。如果你是用自建服务器部署用 Caddy 或 Nginx 配合 certbot 自动签发证书后面我会具体说。4.4 如果你是自建服务器Docker 一行命令部署静态站点很多人手头有台云服务器就希望博客部署在自己的机器上。这样做的好处是可控性强、响应速度快、不依赖第三方平台的审核和限制。我现在的博客就是跑在自建服务器上的用 Docker 部署整个过程简单到出乎意料。先把 Hexo 生成的 public 目录打包传到服务器上或者干脆在服务器上装好 Node.js 环境直接 npm install hexo g 生成。然后写一个极其简短的 DockerfileFROM nginx:alpine COPY public/ /usr/share/nginx/html再执行docker build -t my-blog . docker run -d -p 8080:80 --name blog --restart always my-blog浏览器访问服务器IP:8080就能看到你的博客了。nginx:alpine 镜像非常轻几百 MB 的内存占用一台 1 核 2G 的小服务器跑这个博客绰绰有余。用 Docker 的好处是隔离和可迁移。服务器系统坏了、迁移到另一台机器只需把 Dockerfile 和 public 目录带走重新 build 一次即可。后续想加 Nginx 配置不用直接改宿主机配置而是挂载卷或在镜像里加一行 COPY。如果你安装了域名并已经解析到服务器 IP再配置一个反向代理和 HTTPS。用 Caddy 的话极其省心Caddyfile 里写blog.example.com { reverse_proxy localhost:8080 }Caddy 会自动签发和续期证书不需要任何额外脚本。这样整个自建服务器部署其实就两条 Docker 命令加一个 Caddyfile。5. 自动化部署与回滚用 GitHub Actions 把发布流程炼成一条流水线5.1 为什么本地 hexo d 不够用要引入自动化前几个月我一直在本地执行 hexo g hexo d 发布文章后来发现一个痛点换了电脑之后本地 Node.js 环境、主题版本、插件依赖全部要重新装一遍装完还要手工生成部署。更麻烦的是如果哪次本地环境出问题生产环境就发不了文章了。解决思路就是引入自动化构建。原理很简单文章源码提交到 GitHub 仓库的 source 分支GitHub Actions 在云端自动执行依赖安装、生成静态文件、推送到 Pages 分支。你唯一要做的动作变成 git push剩下全部自动执行。5.2 一条可复制的 GitHub Actions 配置在博客项目根目录创建.github/workflows/deploy.yml文件内容如下name: Deploy Blog on: push: branches: - source jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkoutv4 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 20 - name: Install dependencies run: npm install - name: Clean and generate run: npx hexo clean npx hexo generate - name: Deploy to GitHub Pages uses: peaceiris/actions-gh-pagesv4 with: personal_token: ${{ secrets.GH_TOKEN }} publish_dir: ./public publish_branch: main这个 workflow 的触发条件设为source分支的 push 事件意味着以后写文章提交并推送到 source 分支博客就自动重新构建并部署到 main 分支也就是 Pages 发布分支。这里需要注意本地工作目录已经不需要再保留主题或 public 文件了它们会在云端生成。之前提到需要创建 GitHub Personal Access Token这里同样需要它但更安全的做法是把令牌添加到仓库的 Secrets 中GitHub 仓库 → Settings → Secrets and variables → Actions → New repository secret名字命名为GH_TOKEN值填令牌。自动化流程跑通之后写文章的流程极度简化git add . git commit -m 发布新文章XXX git push origin source等 Actions 跑完打开博客地址就能看到新文章。这个方案不仅省事还天然形成了博客源码的备份本地电脑丢了也不怕。5.3 回滚策略老版本如何快速恢复自动化虽然方便但也会带来新的问题如果某篇文章的代码块或图片把页面炸了怎么办答案是回滚。Git 本身就是版本控制回滚就是 Git 操作。比如最新推上去的文章导致首页样式异常最直接的处理方式是恢复上一次构建的提交。在仓库中找到上一次成功部署的 commit然后执行git revert HEAD git push origin sourceGitHub Actions 会基于回滚后的代码重新构建站点自动恢复到上一个可用版本。这就是把博客源码纳入版本管理最大的意义博客不仅是内容展示还是可回滚的软件项目。我还建议给 Actions 加上一个定时开关或手动触发入口用于临时跳过自动构建。比如你正在改主题测试配置连续 push 十几次每次都会触发完整的构建部署浪费时间和云资源。workflow 里加上on: workflow_dispatch:这样就能在 Actions 页面手动触发构建按需使用。6. 常见问题排查与实测避坑指南6.1 页面渲染成空白或样式全丢多半是这三类原因博客上线之后我遇到的最多的反馈就是「页面看起来不对」或者干脆白屏。仔细排查之后大部分问题集中在三类原因。第一类是主题配置没生效。改完主题 _config.yml 之后没有执行 hexo clean旧 public 目录里残留过期文件导致页面混用了两套样式。解决方法是先 clean 再 generate。第二类是 URL 配置错误。主配置里 url 还是 localhost 的临时值而主题或 SEO 插件用的是绝对路径导致生成的页面里指向的都是 localhost。部署到生产环境前务必把 url 改成真实域名。第三类是 root 路径设置不对。如果你的博客部署在域名子路径下比如https://example.com/blog/主配置里的 root 必须设置为/blog/否则所有 CSS 和 JS 路径都会 404。部署在域名根目录时 root 保持/即可。这一步是最容易让人摸不着头脑的。排查手段并不神秘打开浏览器开发者工具切到 Network 面板看 CSS、JS 请求的地址是什么404 了哪些资源顺着路径就能找出是 URL 还是 root 的问题。6.2 图片显示不出来路径和格式是两大元凶博客里插图是高频操作图片显示不出来最容易踩坑的是路径问题。文章里引用图片推荐用相对路径而不要写绝对路径。例如图片放在 source/images/ 目录下文章里这样引用注意这里的路径要在本地预览和部署后都保持一致。如果部署后图片 404先看 public 目录下图片是否生成再检查路径是否以正确的 root 前缀。还有图片体积问题。很多人图省事直接把手机截图或设计稿原图往文章里丢一张图动辄好几 MB页面加载速度直接被拖垮。文章配图最好过一遍压缩工具squoosh 在线压图就很方便也可以本地用 TinyPNG 命令行工具自动化处理。格式选择上摄影类图片优先考虑 WebP截图类用 PNG色彩简单的图用 PNG 或 WebP 都行。我在实际写作时会把所有原始图片先丢进一个脚本自动压缩并转成 WebP产出压缩率通常能达到 60% 以上。6.3 评论和搜索功能不工作先排查配置匹配再检查依赖giscus 评论不显示我最常犯的检查顺序是这样先看主题配置里的>server { listen 80; server_name blog.example.com; root /var/www/blog; index index.html; location / { try_files $uri $uri/ 404; } }部署前建议先检查 public 目录内容是否完整比如是否有 index.html文章路径是否正常。有时候 hexo g 生成结果本身有问题就不会在服务器端体现出来。6.5 常用命令速查表与标准化操作流最后把整个博客维护过程中最常用的命令整理一次给你一个可以打印贴墙上的速查表。操作场景命令新建文章hexo new post 标题新建页面hexo new page tags本地预览hexo s 或 hexo serve生成静态文件hexo g 或 hexo generate清空旧缓存hexo clean部署到 Pageshexo d 或 hexo deploy一键完成全部流程hexo clean hexo g hexo d安装插件npm install 插件名 --save我自己习惯把整条流程用一个 shell 脚本固化下来避免漏掉 clean 步骤。脚本大概是#!/bin/bash hexo clean hexo generate hexo deploy然后给脚本加执行权限以后发布只需要在终端执行./deploy.sh一个命令。其实不管用自动化 Actions 还是本地脚本核心都是保证这个三步骤的顺序不被破坏。7. 长期维护与写作工作流博客不是搭完就算完7.1 内容备份与多端写作把博客当成一个开发项目来管理博客跑起来只是开始真正的维护工作在日常。一套好的写作工作流会大幅度降低「今天不想写」的启动阻力。我建议把博客项目本身做成一个 Git 仓库把所有文章、主题配置、脚本全部纳入版本控制。每次写完文章commit 消息写得清楚一点比如「新增Docker 部署踩坑记录」。这样文章的内容和时间线都留存也方便回滚。多端写作的问题可以这样解决在 GitHub 上维护一个私有仓库存放全部源文件上班的电脑和家里的电脑都 clone 一份。写作时用 Typora 或者 Obsidian 这类本地 Markdown 编辑器写完后随手 push。Obsidian 支持笔记仓库和插件还能自动同步图片附件我很久以前从 Typora 迁过来之后再没换过。图片管理建议统一放 source/images 目录按照文章名建子目录每篇文章的图片互不干扰。一套清晰的文件夹命名规则比临时乱丢图省下的都是将来找图的时间。7.2 不要把「折腾博客」当成「写博客」这个坑我见过太多人踩了包括我自己。博客平台和主题设置总有无穷无尽的 DIY 空间今天换个主题明天调个颜色后天研究一下暗黑模式大后天又想加个标签页动画。折腾本身没有错但要是连续几周都没写一篇文章而只是在改博客框架就该提醒自己停下来了。博客的核心永远是内容而不是内容展示的容器。我给自己定下的规则是每做一次主题或功能调整至少要配一篇新文章输出否则不做。执行下来之后内容和系统基本实现了良性循环。7.3 关于常年运行的一些亲测经验部署上线不等于万事大吉。我运营了一阵子之后总结出几个对稳定性影响很大的例行检查项。第一HTTPS 证书续期验证。如果你用的是自建服务器加 certbot 自动续期记得设置一个定时任务检查证书剩余有效期在大版本系统升级之后务必手动验证一次证书链是否完整。第二静态站点的日志监控。我的服务器上跑了一个轻量监控脚本每天检查域名响应状态、磁盘使用率、日志文件大小异常时自动发提醒。别看博客小服务器挂了正好你又不在电脑旁一挂就是好几天无人知晓。第三读者评论的及时回复。giscus 的评论都进 GitHub Discussions我把它接入 Telegram 或邮件提醒基本能做到 24 小时内回应。对读者认真是博客长期保持活跃的最好方式。从零到部署其实并没有那么复杂。先跑通最小链路再逐步加功能最后形成属于自己的稳定发布流程整个系统就会像流水线一样安静地运转。你只需要在这条线的一端写文章另一端的世界自然就看到了。