静态博客生成器 + 代码托管 Pages：零成本搭建个人博客

很多人做个人博客的第一步就走偏了先挑建站程序再找虚拟主机接着纠结一年几百块的服务器费用最后卡在备案、环境、数据库权限上热情消耗殆尽站点连首页都没跑起来。我见过太多这样的半成品。真正省事的路线其实是反过来的——先想清楚博客的内容形态是读多写少的静态文本再选一个静态博客生成器把 Markdown 编译成 HTML最后把编译产物丢到代码托管平台自带的 Pages 服务上托管。整套组合的边际成本是零不用买服务器不用配数据库不用管运行时环境代码托管平台负责 CDN 分发和 HTTPS 证书。这篇文章就把这条链路从头到尾拆开包括选型理由、最短实操路径、上线后真正花时间的地方以及我踩过的几个必须知道的坑。不管你是完全没碰过命令行的新手还是搭过动态博客想迁移过来的老手都能从中拿到能直接抄的东西。1. 为什么静态生成器 代码托管 Pages是零成本方案里最抗打的组合1.1 静态博客到底省掉了哪些东西先把这个方案的账算清楚。传统的动态博客比如各类基于 PHP 或 Java 的建站程序在运行时需要三样东西一个能执行脚本的运行环境、一个存数据的数据库、一个持续在线的进程。这三样东西恰好就是成本和安全风险的全部来源——运行环境要打补丁数据库要备份和防注入进程挂着就要付服务器钱。静态博客把这三样一次性砍掉文章源文件是纯文本构建过程在你自己的电脑上跑完最终产出是一堆.html、.css、.js和图片托管方只负责把这些文件当静态资源发给浏览器。这个变化带来的不只是省钱。静态文件的攻击面极小没有登录接口、没有数据库查询、没有后台管理页面常见的注入和越权问题基本无从谈起访问速度方面静态资源天然适合被 CDN 缓存用户请求打到离他最近的节点不需要回源执行任何逻辑。还有一点经常被忽略你的文章源文件是纯文本天然适合用 Git 管理。每一次修改都有版本记录误删可以回滚换电脑只要克隆仓库这比任何博客后台的回收站都可靠。注意静态不等于不能有交互。评论、搜索、阅读量统计这些功能静态站点是通过调用第三方服务或前端本地索引来实现的功能上并不缺失只是实现方式从服务端算变成了浏览器算。1.2 Pages 服务在这套方案里扮演的角色代码托管平台提供的 Pages 服务本质是给你一个仓库配一个静态文件服务器。你把构建好的 HTML 目录推进指定分支平台检测到变更就自动发布并分配一个默认的二级域名顺带把 HTTPS 证书也签好。很多人只知道它能放项目文档实际上放个人博客完全够用——流量不大的个人站点几乎不会碰到配额上限。它的价值在于把部署这件事压缩成一次git push。没有 FTP 上传没有宝塔面板点来点去没有文件传上去但权限不对导致 403这种玄学问题。你在本地看到什么样推上去就是什么样。而且因为源文件也在同一个平台写作和发布共用一套版本控制心智负担很低。还有一个隐性好处默认域名自带可信度。别人看到一个结构规整、HTTPS 正常的站点第一印象会比一个奇怪的免费空间域名好得多。等你确定要认真做下去再挂自己的域名也不迟那时域名解析只是加一条记录的事。1.3 10分钟这个承诺该怎么理解标题里的 10 分钟指的是从零到一个能在浏览器里打开、能看到自己第一篇文章的最小可访问站点所花的时间。这个目标是可以达成的注册账号两三分钟装好运行环境和 Git 五分钟跑初始化命令、换掉默认配置、推一次代码剩下的时间够你喝口水。但要说清楚这 10 分钟里不包含选主题、调样式、配评论、接域名。那些属于把站点变成你想要的样子是一个持续的过程头一次认真做大概要花一到两个小时之后每次换主题半小时起。把这两件事分开看心态会平稳很多。我见过有人因为说好 10 分钟结果搞了一下午而放弃问题不在技术上在于预期错了。2. 十分钟倒计时开始前先把这三样东西备齐2.1 本地运行时为什么静态博客还需要装 Node这里有个常见的困惑既然是静态的为什么还要装运行时答案在构建环节。静态生成器本身是个程序它要读取你的 Markdown、套用模板、生成 HTML这个过程需要运行环境。不同生成器的依赖不同基于 JavaScript 的那一类需要 Node 环境基于 Go 的那一类只需要一个可执行文件基于 Ruby 的那一类需要 Ruby 环境。我的建议是新手优先装 Node 的长期支持版本理由是生态最厚、中文资料最多、出问题最容易搜到答案而且后面装主题、装插件基本都走同一套包管理命令学一次到处能用。安装时注意两点一是装完要重新打开一个终端窗口否则环境变量不生效二是在终端里敲版本号验证一下能打印出版本号才算真的装好了。Git 也是必需的哪怕你只用最基础的几条命令。它的作用有两层本地做版本管理以及把代码推到托管平台。安装时一路默认即可装完同样验证一次。node -v npm -v git --version三条命令都能输出版本号环境就算齐了。这一步卡住的人不少多数是装完没重开终端或者公司电脑的权限策略拦了安装包这类问题只能靠换一台机器或者找管理员解决绕不过去。2.2 托管平台账号注册时容易忽略的两个细节账号注册本身没什么门槛但有两点值得提前处理。第一是用户名会成为默认域名的一部分而且后期改动会影响已有的访问链接所以注册时就想好一个体面、简短、和你内容定位相关的名字别用一串随机数字。第二是邮箱一定要验证很多平台的自动构建功能在邮箱未验证时是受限的你会遇到代码推上去了但站点没更新这种让人抓狂的现象排查半天发现是账号状态问题。如果你打算以后挂自己的域名账号注册这一步就可以顺手把域名买了但不用急着解析。域名和托管是两件独立的事先把站点跑通再处理域名顺序反过来容易在 DNS 生效等待期里干着急。2.3 一份目录规划别让源码和产物混在一起这是准备工作里最有价值的一条经验。静态生成器构建后会产出一个输出目录不同工具叫法不同可能是public、dist或docs这个目录里是最终要发布的 HTML。很多教程图省事让你把整个项目连同输出目录一起提交用同一个分支发布。短期没问题长期会很难受每次构建都会产生大量文件变更提交记录里全是编译产物你根本看不清哪次改了什么内容。正确的做法是源码和产物走两条线主分支只存源文件Markdown、模板、配置文件构建产物由平台在发布时自动生成或者推到另一个专用分支。这样提交历史干净回滚也精准。这个规划在开始动手前花两分钟想清楚能省掉后期迁移的一堆麻烦。项目作用是否提交到主分支Markdown 文章目录存放正文源文件是主题配置与模板覆盖站点外观是站点配置文件标题、地址、语言等是构建输出目录最终 HTML否由自动构建生成依赖安装目录第三方包否加入忽略文件3. 生成器选型三类主流工具到底该挑哪个3.1 从你更怕什么出发做选择选型文章通常会罗列一堆参数其实对个人博客来说决定性因素只有一个你更怕慢还是更怕折腾。怕慢的人文章数量一旦上去每次本地预览都要等十几秒甚至更久写作节奏会被打断这类人适合构建速度极快的工具典型代表是编译型语言写的那一类几百篇文章构建通常在一秒级完成。怕折腾的人希望主题多、插件全、遇到问题能搜到中文答案那就选生态最厚的那一类代价是构建速度一般需要装运行时环境。还有一个维度是迁移成本。如果你的文章已经是 Markdown 格式换生成器的成本其实很低——正文不用动主要改的是文件头的元信息字段和目录结构。所以第一套方案选错了并不是灾难先用起来更重要。维度生态型JS 系速度型Go 系极简型Ruby 系需要额外运行时是否单文件可执行是首次构建速度中等极快中等偏慢主题与插件数量最多较多中等中文资料密度高中等中等适合人群想折腾外观的新手文章多、追求效率已有相关环境经验我的实际建议是第一套用生态型跑通全流程把部署链路彻底搞明白等你写到五十篇以上、开始嫌预览慢的时候再考虑迁移。那时候你对 Markdown 元信息、目录结构、部署方式都熟了迁移是半天的事。3.2 初始化命令背后的目录结构不管选哪个工具初始化命令做的事情都类似创建目录、拷贝一份默认模板、生成示例文章、装好依赖。理解它生成了什么比记住命令本身重要。# 以生态型工具为例初始化一个站点 npx create-site my-blog cd my-blog npm install初始化完成后目录里通常有这么几块source或content存放文章源文件themes存放主题根目录的配置文件定义站点标题、地址、语言、分页等还有一个package.json记录依赖和脚本命令。配置文件里的站点地址字段是最容易出错的地方后面踩坑章节会专门讲。初始化自带的示例文章不要急着删它是你验证构建链路是否通畅的第一个样本。等站点能正常访问了再换成自己的内容排查问题时能少一个变量。3.3 本地预览写作阶段最重要的一个命令启动本地服务的命令通常是serve或server跑起来后终端会打印一个本地地址浏览器打开就能看到站点。这个本地服务带热重载你保存 Markdown 文件浏览器会自动刷新。这个环节的价值在于把反馈周期压到最短。写作时你会频繁调整标题层级、图片位置、代码块格式如果每次都要推送到线上才能看到效果效率会低到无法接受。养成先本地预览确认没问题再推送的习惯能避免大量推上去发现排版崩了又改一次的无谓提交。提示本地预览正常但线上不正常九成是路径或地址配置问题。反之亦然。遇到这种不一致先对比两边生成的 HTML 里资源引用路径的差异比盲目改配置快得多。4. 从空目录到本地跑起来最短路径实操4.1 站点配置文件的五个必改字段初始化完成后第一件事不是写文章是改配置。默认配置里的站点标题往往是工具名地址字段可能是示例域名这些东西不改构建出来的页面标题和分享卡片全是错的。必改的字段大致是这几类站点标题、副标题或描述、作者名、语言、站点地址。语言字段直接决定日期格式和界面文案中文站点一定要设成对应的语言代码否则归档页会显示成英文月份。# 站点基础配置示例 title: 某个人的技术笔记 subtitle: 记录踩过的坑和绕过的弯 description: 前端、工具链与工程实践 author: 某开发者 language: zh-CN timezone: Asia/Shanghai # 站点地址注意末尾不要多写斜杠 url: https://你的用户名.example.com时区字段值得单独说一下它影响文章的发布时间戳而时间戳又影响文章排序和归档分组。如果你在晚上十一点写文章时区没配对可能出现文章被归到前一天甚至排序错乱的情况。这个坑后面还会提到。4.2 写第一篇真正的文章文章的源文件通常放在指定的目录下文件名会成为访问路径的一部分。这里有个建议文件名用英文或拼音加短横线别用中文。虽然现在的工具对中文路径支持已经不错但在某些平台上中文文件名经过编码后生成的链接会变得又长又难读分享出去很难看。文章开头的元信息区块不同工具叫法不同有的叫 front-matter有的叫头部配置是必须写的它定义了标题、日期、标签、分类这些结构化信息。--- title: 我的第一篇博客 date: 2025-01-15 20:30:00 tags: - 建站 - 笔记 categories: - 随笔 --- 正文从这里开始。Markdown 语法直接写就行 标题、列表、代码块、表格都支持。日期格式要严格按照示例来缺了时间部分可能导致排序异常。标签和分类的区别在于分类通常是一对多的树形结构标签是扁平的关键词集合。个人博客不必纠结我的习惯是分类只用几个大类标签随意打方便日后检索。4.3 本地跑通后的三个自检动作本地能打开不代表配置正确。我会做三个检查第一点开任意一篇文章看标题、日期、标签是否正常渲染第二看页面底部或侧边栏的站点名是不是你配的那个第三打开浏览器开发者工具的网络面板看有没有资源加载失败状态码 404。第三个检查最容易被跳过但它能提前暴露路径问题。本地服务有时会自动处理路径差异把问题藏起来等推送到线上才爆发。花一分钟看一眼网络面板比上线后抓瞎要划算。5. 把站点推上代码托管平台Pages 部署链路拆解5.1 三种部署方式为什么我只推荐第三种部署这件事有三条路可走复杂度递增可靠性也递增。第一种是手动构建后上传产物。在本地跑构建命令把输出目录里的文件通过网页界面上传到平台。这种方式最直观但完全不可持续——每次改一篇文章都要重复一遍手工操作且没有任何版本记录。第二种是本地构建后一键推送。生态型工具通常提供部署插件配好仓库地址和目标分支一条命令就能构建并推送。比第一种省事但依赖你本地环境的正确性换台电脑就得重新配一遍而且构建过程不可追溯。第三种是平台自动构建。你把源码推上去平台检测到变更后自动安装依赖、执行构建、发布产物。前期配置稍微麻烦一点但配好之后就是推代码即发布换电脑不用重配构建日志可查失败有通知。我强烈建议第三种。它不是最省事的但它是唯一能让你在半年后还愿意继续更新博客的方式。前两种的问题不在于麻烦而在于麻烦会累积成放弃的理由。5.2 自动构建配置的关键字段自动构建的核心是一份配置文件告诉平台用什么环境、装什么依赖、执行什么命令、发布哪个目录。不同平台的字段名和文件位置有差异但逻辑是一致的。# 自动构建配置示例字段名随平台略有差异 构建环境: 指定运行时版本 执行步骤: - 拉取源码 - 安装依赖 - 执行构建命令 - 将输出目录作为发布产物 触发条件: 主分支有新的提交配置时有三个点必须对上运行时版本要和本地一致本地用某个大版本线上配另一个很容易出现依赖装不上构建命令要和项目脚本里定义的一致输出目录要和配置文件里定义的输出路径一致。这三处任意一处对不上表现都是构建成功但站点是空的或者构建直接失败。注意首次配置自动构建时先在平台上手动触发一次盯着日志从头看到尾。日志里会明确写出每一步的耗时和结果比你在本地猜要快得多。5.3 分支策略源码和产物到底该放哪这是部署环节最需要想清楚的问题。常见的有两种安排源码在主分支自动构建把产物推到专门的发布分支或者源码在主分支平台直接从构建产物发布不落地到分支。我倾向第一种因为它留下了产物的历史快照。万一某次发布出了问题你可以直接对比前后两次产物分支的差异定位是哪次改动导致的。第二种更干净但排查问题时少了一份参照。无论选哪种都要确保输出目录被写进了忽略文件。我见过有人把构建产物一起提交结果每次构建都产生几百个文件的变更提交记录一片红绿完全没法看。# 初始化并推送源码 git init git add . git commit -m 初始化站点 git branch -M main git remote add origin 你的仓库地址 git push -u origin main推送完成后回到平台页面确认自动构建是否被触发。如果几分钟后站点地址还是 404先看构建状态再看分支设置里发布源有没有指向正确的分支和目录。这两个地方是新手最常卡住的位置。6. 站点上线后真正耗时的地方主题、评论、搜索与域名6.1 换主题不是复制粘贴那么简单主题决定了博客的观感也是上线后第一个想动的东西。换主题的流程通常是下载主题到主题目录、修改站点配置指定使用哪个主题、按主题文档调整它的专属配置。麻烦在于每个主题都有自己的配置体系和依赖。有的主题需要额外装渲染插件来支持数学公式有的需要装图片处理插件来生成缩略图有的对文章元信息字段有额外要求。直接套用别人的配置文件经常出现页面能打开但某些区块空白的情况原因往往是你没装它依赖的插件。我的做法是换主题后先不加任何自定义用默认配置跑一遍本地预览确认基础功能正常然后一次只改一个配置项改完刷新看一眼。批量改完再刷新出问题时根本不知道是哪一项导致的。6.2 评论和搜索静态站点的两块补丁静态站点没有后端评论功能需要借助外部服务。主流的做法有两类一类是基于仓库讨论区的评论组件把每条评论存成一条讨论记录另一类是独立的第三方评论服务注册后拿到一段脚本嵌进页面。选择时重点看两点是否需要用户登录要求登录的会劝退一部分读者但能有效减少垃圾评论以及数据存在哪里存在别人服务器上的服务关停就全没了。个人博客评论量通常不大我更倾向基于仓库讨论区的那种数据跟着仓库走可控性高。搜索功能则通常靠前端本地索引实现构建时把所有文章的标题、摘要、正文生成一个索引文件页面里加载这个文件用户输入关键词时在浏览器里做匹配。这个方案零成本、无需外部服务缺点是文章特别多时索引文件会比较大首次搜索有加载延迟。个人博客几十上百篇的规模完全够用。6.3 自定义域名与 HTTPS 的完整链路默认的二级域名能用但不好看也不好记。挂自己的域名需要三步买域名、配解析、在仓库里声明。解析这一步要分清两种记录类型如果托管平台给的是固定 IP配 A 记录如果给的是一个别名地址配 CNAME 记录。根域名不带 www 的那种通常不支持 CNAME这是协议限制所以很多人的做法是根域名配 A 记录指向平台 IP同时把 www 子域配 CNAME再在平台侧设置主域名跳转。在仓库里声明域名的方式通常是放一个纯文本文件内容就是你的域名一行不带协议头。这个文件必须放在输出目录的根很多人放在源码根目录构建后没被复制过去导致每次发布后自定义域名设置被重置站点又跳回默认地址。这个问题非常隐蔽表现是配好了过几天又失效了。HTTPS 证书一般由平台自动签发和续期前提是解析已经生效。刚配好解析时证书签发可能失败等解析完全生效后重新触发一次即可。别在解析还没生效时反复重试那只会浪费时间。7. 我踩过的七个坑路径、构建、缓存与子目录7.1 站点地址配错导致样式全丢这是最高频的问题表现是页面能打开标题文字都在但完全没有样式像一份裸 HTML。原因几乎总是站点地址字段和实际访问地址不一致。如果你的站点不是挂在域名根目录而是挂在类似/blog/这样的子路径下那么配置文件里除了完整地址还要单独指定根路径字段。只改地址不改根路径生成的 CSS 引用会指向根目录浏览器去根目录找文件自然 404。# 站点挂在子路径时的正确配法 url: https://你的用户名.example.com/blog root: /blog/判断方法很简单打开页面按 F12看样式文件的请求地址是什么。如果请求的是域名/css/style.css而你实际的文件在域名/blog/css/style.css那就是根路径没配。7.2 文件名大小写本地没事线上崩了Windows 和 macOS 的默认文件系统不区分大小写Linux 区分。你在本地引用一张图片写成Images/cover.png实际文件叫images/cover.png本地预览完全正常推送到线上就变成裂图。这个坑的恶心之处在于它只在线上暴露而且往往是你完全没注意过的地方。规避方法文件和目录统一用小写字母加短横线命名图片引用路径严格照抄实际文件名。如果文章多构建后可以扫一遍输出目录检查有没有引用了不存在文件的路径。7.3 时区没配文章排序乱成一锅粥前面提过时区字段这里展开说。文章的显示日期来自元信息里的时间但归档分组、前后篇导航、首页排序这些逻辑常常还依赖构建时的时区换算。时区配错晚上写的文章可能被算到前一天出现最新文章排在后面或者同一篇文章出现在两个归档月里的怪异现象。修复很简单配置文件里显式指定时区元信息里的时间写完整的年月日时分秒别只写日期。写日期不写时间时很多工具会默认成零点跨时区换算后可能直接退一天。7.4 浏览器缓存让你以为改了没生效改了样式、推了代码、构建成功刷新页面还是老样子。这种情况十次里有八次是缓存。静态资源的缓存策略通常比较激进浏览器会优先用本地副本。排查顺序是先强制刷新大多数浏览器是按住 Shift 点刷新还不行就开无痕窗口访问再不行就在开发者工具里勾选禁用缓存。确认是缓存问题的标志是无痕窗口正常普通窗口不正常。这不是代码问题别去改配置。7.5 图片放哪仓库内和外部图床的取舍博客总要放图。两条路图片跟着仓库走或者传第三方图床拿外链。放仓库里的好处是永不失效、随版本管理、迁移无痛缺点是仓库体积会涨克隆变慢。我的建议是放仓库里但做两件事控制体积一是上传前压缩截图类图片转成压缩率更高的格式很多截图工具本身就带压缩选项二是按年月分目录存放避免单个目录堆几千个文件。第三方图床的优点是写作时贴图快缺点是你把内容的完整性交给了别人的服务。我用过几个最后都因为服务调整而出现裂图只能一篇篇回去修。个人博客的图片量其实不大放仓库里更省心。7.6 构建成功的假象产物是空的有时候构建日志显示成功但站点打开是空白页或者 404。这种情况通常是输出目录配置和实际生成的目录不一致。构建命令生成了public但发布配置里写的是dist平台兴高采烈地发布了一个不存在的目录当然什么都没有。排查方法看构建日志的最后几行通常会打印生成了多少个文件再对比发布配置里的目录名。另外一个可能是构建命令根本没执行只跑了安装依赖那一步——检查配置里步骤顺序有没有写错。7.7 改了配置但文章不更新这个问题的成因比较隐蔽某些工具为了加速构建会把已生成的内容缓存起来判断依据是文件的修改时间。如果你用脚本批量修改了文章但没改变时间戳构建时可能认为文件没变而跳过生成。修复方式是清除本地缓存目录后重新构建或者在构建命令里加上强制全量构建的参数。这个坑不常遇到但一旦遇到会非常迷惑——明明文件改了本地预览也是新的构建出来的却是旧的。现象最可能的原因快速验证方式页面无样式站点地址或根路径配错看样式请求的完整路径图片裂图文件名大小写不一致对比引用路径和实际文件名文章顺序错乱时区或日期格式问题看归档页的分组月份改了没生效浏览器缓存无痕窗口访问站点空白输出目录配置错误看构建日志的文件数域名设置失效声明文件没放对位置检查产物目录根下是否有该文件8. 长期维护一篇文章从草稿到发布的固定动作8.1 把写作流程固化成四步博客能不能坚持下去取决于写作流程顺不顺。我把自己的流程固定成四步每一步都很短。第一步新建文章文件写元信息正文先只写标题和几句提纲。这一步花两分钟目的是把想法存下来防止过两天忘掉。第二步抽时间把提纲扩成正文这一步不追求完美先把话说完整。第三步本地预览检查代码块、表格、图片这些容易崩的元素顺手改掉明显的错别字。第四步提交推送等自动构建完成打开线上地址确认一次。这四步里最容易跳过的是第四步的线上确认。我吃过亏本地预览一切正常推上去发现某个只在线上才触发的路径问题等读者反馈才知道。多花三十秒看一眼能省掉后面的尴尬。8.2 草稿机制别让半成品出现在列表里大多数生成器都有草稿功能标记为草稿的文章在本地预览时可见但不会出现在正式构建的列表里。这个功能值得用起来。用法很简单在元信息里加一个状态字段或者在专用的草稿目录里写。写好之后再改状态发布。这样你的站点上永远只有完整的文章不会出现标题点进去只有两行字的情况。对读者体验是小事对自己的心理感受是大事——看着列表里一堆半成品写作的动力会被消耗掉。8.3 备份与迁移你的资产到底是什么想清楚一件事博客的真正资产是那一堆 Markdown 文件和图片不是主题不是配置不是服务器。主题随时可以换配置随时可以重写文章丢了才是真的损失。所以备份策略只需要保证一件事文章和图片在至少两个地方存在。最省事的做法是仓库本身就是备份再加上本地一份完整拷贝。如果你只在网页上写文章有些平台支持在线编辑那就定期把仓库克隆到本地一次。迁移也一样简单。换生成器只需要改元信息字段和目录结构正文一个字都不用动换托管平台就是把仓库推过去改一下自动构建配置。真正麻烦的只有一处旧链接会失效。如果你已经积累了一些外部引用迁移时最好保留原有的路径规则或者在旧地址上做跳转。# 定期把整个站点仓库拉到本地做一份冷备份 git clone 你的仓库地址 backup-$(date %Y%m)8.4 什么时候该考虑升级方案零成本方案不是终点但绝大多数个人博客走不到需要升级的那天。判断标准很朴素当你开始因为技术限制而放弃想写的内容时才需要考虑升级。比如你想做一些需要服务端逻辑的交互或者流量大到静态托管的配额不够用或者需要多人协作投稿。这些情况出现之前把精力放在写作上收益更高。我见过太多人花了两个月折腾架构文章数停在个位数。工具是给内容服务的别反过来。9. 关于这套组合我最后想说的几点搭博客这件事最大的误区是把搭建当成目标。真正难的部分从来不是那十几条命令而是坐下来把想法写成一篇结构完整、对别人有用的文章。零成本方案的价值在于把技术门槛压到接近零让你在产生写作冲动的那一刻能立刻打开编辑器开始写而不是先花一周研究服务器配置。具体到操作上我给三条最实在的建议。第一先把最小可访问站点跑通再谈美化。主题可以换域名可以加但前提是那条发布链路你得先走通一遍知道每一步在干什么。第二配置文件里的地址和路径字段改完一定要在线上验证一次。本地预览会掩盖太多路径问题这是新手最容易翻车的地方。第三给自动构建配一个失败通知。构建失败时你不会立刻知道可能过了几天才发现站点已经好几天没更新那种感觉相当糟糕。我自己现在维护着两个这样的站点一个写技术笔记一个放零散的生活记录。日常操作就是打开编辑器写 Markdown写完推一次代码剩下的交给平台。这套流程跑了几年除了偶尔因为改配置踩一两个坑没有出过别的问题。如果你也在犹豫要不要开始我的建议是别再比较方案了随便挑一个跑起来第一篇文章发出去剩下的问题都会在过程中自然解决。