算起来我折腾自己的博客已经有一周了。最开始只是想在主页上放个像样点的地方写写笔记结果一搜“个人博客怎么搭”扑面而来的是各种静态站点生成器、主题市场、部署方式、评论插件、图床方案每个选项下面还有一堆子选项收藏夹越攒越长主页却一个字都没写出来。这篇《我的Hexo博客搭好了01》就是记录这段“选择困难症发作”的过程——最终我选了Hexo不是因为它在所有维度上都赢而是因为它恰好匹配了“先把内容写起来”这个诉求。如果你也正在框架、主题、部署这些岔路口上反复横跳这篇文章应该能帮你省下不少纠结的时间。1. 框架选型为什么绕了一圈还是Hexo1.1 候选清单里到底有哪些方案我为什么没有选它们的理由在决定用Hexo之前我其实把主流方案都过了一遍。当时盯着候选清单脑子里大概有以下几类Go语言写的那款极速生成器号称构建速度碾压一切尤其适合上千篇文章的大型站点。我看了看自己的需求——大概只有几十篇内容构建快那几秒根本体现不出来反而它的主题生态和插件社区相对没那么丰富。Vue驱动的文档站方案适合写项目文档或者知识库页面交互丝滑但个人博客场景里很多效果反而有点重而且它的内容组织方式是围绕导航结构来的跟“写随笔”的调性不太搭。Ruby社区的老牌方案历史最久稳定性好但Ruby环境在Windows上装起来比较麻烦某些依赖包在这一代机器上编译还会报错我劝退了。最后就是Hexo。理由很朴素Node.js环境对我这种做前端出身的人来说几乎是零门槛生态成熟中文资料多遇到问题一搜就有解决方案而且主题选择极多总能找到一款符合审美的。你可能会觉得“中文资料多”这个理由有点偷懒但实操下来它真的能救命。很多奇怪的小问题比如图片路径不对、部署后样式丢失、分页失效老玩家早就踩过一遍了社区里翻一翻就有处理思路。个人博客是个长线项目后续维护成本比初次搭建成本更值得重视这个维度上Hexo优势非常大。1.2 性能焦虑是伪需求生成速度完全可以接受我还认真考虑过一个问题Hexo的构建速度会不会太慢尤其是文章多起来之后。当时看到有人吐槽“几百篇文章就要半分钟”心里确实咯噔一下。后来我用二三十篇文章做了一次实测从执行生成命令到文件全部输出大概也就两三秒就算之后文章写到两三百篇这个速度还在可接受范围。说白了个人博客的构建频率是“每次写完文章跑一次”不是“每次请求都重新渲染”哪怕是十秒也问题不大。为这点收益去学一套新生态长期来看不划算。1.3 初始化环境时的几个坑在我开始动手之前有几个环节是绕不开的顺手分享一下当时踩到的点装Node.js建议直接上长期维护版本别追最新版避免某些依赖包还不兼容。npm换源这个操作强烈建议做否则下载依赖时会等到怀疑人生。换好后下载速度能从几十KB跳到几MB。Hexo脚手架装完之后目录里会生成一个package.json、一个配置文件_config.yml、一个source文件夹。很多人一上来就想改主题我建议先随便写一篇Hello World跑一遍本地预览命令确认全流程是通的再开始折腾别的东西。本地预览和生成是两个概念。预览是启动本地服务实时看效果生成是把全部页面输出到public目录。这个区别搞清楚了后面部署基本不会蒙圈。初始化这一步没太大难度真正让我原地打转的反而是下一层主题。2. 主题才是真正的选择困难区我在三款方向之间的反复横跳2.1 主题筛选的三个硬指标Hexo的主题市场一打开几百款主题摆在面前从极简文字流到卡片大图流从双栏到三栏从深色到浅色还有不少带白天黑夜切换的。我第一天就在这个页面上耗了两个小时收藏了二十多款最后都不敢往下翻因为翻得越多选择越难。后面我给自己定了三条硬指标才慢慢把范围缩小下来观感必须耐看。这是最主观的一条我的标准是“第二天早上再看一眼不觉得腻”。很多主题第一眼惊艳但花哨的元素多看两天就会觉得满屏都是噪音。移动端表现要过关。现在一大半流量都来自手机主题如果在小屏上排版稀烂体验直接劝退我会打开预览模式把窗口缩到手机宽度来回划几屏再决定。维护活跃度和踩坑资料同样重要。有些主题作者已经多年不更新遇到兼容性问题只能自己硬扛反过来热门主题哪怕偶尔有bug搜一下也能找到别人给的补丁方案。按这三条筛完收藏夹里真正能打的其实也就剩五六款。2.2 我从哪几个方向里选当时我纠结最久的大体可以分成三类方向极简文字流。页面非常干净几乎只有内容、目录和少量导航阅读体验特别好加载也快基本不会出视觉上的幺蛾子。卡片风格。每篇文章都有封面图和摘要卡片首页显得很精致内容一多就有“杂志感”。但封面图从哪里来是个大问题如果每篇都自己做封面坚持不了几天。文档风。整个站点像一套软件文档导航在左侧正文在右侧看起来很专业。但用在个人博客上会显得有点冷也缺少一点“个人感”。我在极简和卡片之间反复横跳了好几次。后来想明白一件事博客的核心是文字本身。如果主题太抢眼读者点进来第一眼看到的是排版而不是内容那就本末倒置了。最终我选了极简方向唯一的妥协是保留目录侧栏和代码高亮配色这样既不会干扰阅读又能兼顾技术文章的可读性。事后证明这个选择是对的后续我完全没再动过换主题的念头。2.3 最终配置清单改完这些就够了主题选定之后真正需要改的配置其实非常有限。我当时对着配置文件一项项试最后沉淀下来一份清单给同样在折腾的人一份参考站点语言改成zh-CN菜单栏换成首页、归档、关于三栏够用了。站点描述写清楚别只放一句“xx的博客”描述会直接影响后续被搜索到的概率。头像换成本人照片社交链接只保留两三个常用的。代码块的配色选一款护眼一点的深色窄边框方案就挺好不要默认的高亮蓝。归档页面、标签页面、关于页面这些独立页面要手动创建建好之后记得在菜单里挂上链接。首页显示的文章摘要长度稍微调短一点让首页更紧凑。改配置之前我顺手把原主题的_config.yml备份了一份。这个习惯后来救了我一次——某次我改错了一个缩进导致全站报错直接回滚备份就恢复了非常省事。3. 部署路线免费托管和自建服务器的取舍3.1 三条路的成本对比框架和主题定下来之后下一个纠结点是部署。我把主流方案分成了三类列了个比较方案花费上手难度访问速度后期维护代码托管平台的静态站点托管服务免费低国内时好时坏几乎不用管国内代码托管平台的Pages服务免费/低价低快偶尔要重新绑定云服务器自建按年收费高快要维护环境、续费、防攻击考虑到我当时只是想把博客跑起来不想一上来就背上维护服务器的担子我选了第一种方案。它的操作路径最短仓库创建好构建产物推上去访问链接就有了。至于访问速度在国内不太稳定这个问题我目前还能接受毕竟访问个人博客的核心场景还是以内容阅读为主等以后流量大了再考虑升级方案也不迟。3.2 从零到上线的完整操作记录我梳理一下这次部署的完整流程照着走基本不会出大问题在代码托管平台上新建一个仓库仓库名建议和项目名一致。我当时因为大小写不一致部署后资源路径全404了排查了半天才发现是仓库名的问题。在Hexo的配置文件里把站点地址改成托管服务分配给你的那个地址注意带不带子路径会直接影响资源能否加载。安装官方提供的Git部署插件然后在配置里补上仓库地址和目标分支。依次执行清理、生成、部署三条命令hexo clean、hexo generate、hexo deploy。第一次部署成功后访问链接能看到页面那一刻还挺有成就感的。如果样式全乱套八成是站点地址填错或者仓库路径写错优先检查这两处别急着改代码。我特别想提醒一句hexo clean不是可选项。有时候改了主题配置没清理旧缓存直接重新生成页面会出现一些诡异的历史残留每次都先清理再生成能少踩很多坑。3.3 自动化发布的升级玩法手动敲部署命令其实已经很顺了但每次写完文章还要打开终端执行两条命令懒癌发作时还是会拖。后来我配置了自动化工作流把源码推送到仓库的主分支后自动完成依赖安装、构建产物生成并把结果推送到发布分支。这样我只需要做一件事——写代码提交剩下都交给流水线跑。这个流程的收益不只是省几秒时间。发布过程被固定下来之后不会再出现“本地能跑、线上挂了”这种问题因为每次构建都是在同一套干净环境里完成的依赖版本也更可控。建议不熟悉的新手先把手动流程跑通再加自动化否则出问题时反而多了个排错变量。4. 图床、评论、域名还没写文章就差点被配套服务劝退4.1 本地图片仓库膨胀与图床转移博客写起来之后图片处理是绕不开的一环。最开始我图省事直接把截图丢进本地文件夹里。写了几篇文章之后发现仓库体积迅速膨胀打开项目都变卡了而且构建出来的页面里图片资源会占用大量空间。于是我开始研究图床方案。各家云厂商都提供对象存储服务差别主要在于免费额度、访问速度、是否要备案、控制台好不好用。我最后选了“小图放本地、大图和截图放云存储”的混合方案文章里涉及的大尺寸截图放到对象存储小图标、站内图片继续用本地相对路径。这样既不拖慢仓库克隆速度也能有效控制页面加载体积。如果你也打算用云存储当图床有几个配置很容易踩坑存储桶的公共读权限必须打开否则图片会403上传后要确认返回的链接是直接访问的直链还有防盗链配置一开始别急着开等发现有外部盗链再处理。4.2 评论系统我为什么最后决定先不装评论区大概是所有配套服务里最折磨人的。我当时了解了几个方向一类是第三方托管评论功能丰富、登录和通知都做好了但加载速度偏慢而且数据都搁在别人服务器上另一类是借助代码托管平台登录授权的开源评论方案跟博客气质很搭但需要手动初始化配置每个文章页都要做映射出错率不低还有一类是自建评论后端自由度最高但对我来说维护成本明显超预算。选来选去我的决定是先不装评论。写博客的初衷是把想法梳理清楚而不是立刻迎来一群人来讨论。等真有读者反馈需求了再补一套评论系统也不迟。内容平台上留言功能固然重要但对我来说“先有内容”比“先有互动”更优先。4.3 域名、统计、搜索等周边能省则省除了图床和评论还有一堆周边选项在排队要不要买独立域名要不要加访问统计要不要集成站内搜索我最后的选择是域名先不买先用托管平台送的二级地址统计脚本加了一个轻量的开源埋点能看每天访问量和来源就够了搜索功能直接交给浏览器的站内搜索能力站点内容不多时根本用不上专门的搜索引擎插件。这些“能省则省”的决定有一个共同逻辑凡是不影响内容发布的事情都先往后放。博客这事情边际成本最高的是“写”本身而不是那些花哨的功能。5. 事后复盘选择困难症到底在困难什么5.1 哪些选择真的影响长期成本当时让我纠结到半夜的选项很多其实并不值得那么多时间。回看整个过程真正决定后面成本的是两类选择内容存储格式。文章如果用的是通用格式比如纯文本带标题结构将来换任何工具都能轻松迁移反过来如果用了某个工具的私有格式想搬走就得写脚本。部署和发布链路。是手动发布还是自动化发布是多平台同步还是只留一个入口这些决定会影响每次更新要花的时间。好在这些都可以在中途调整不必一步到位。至于主题配色、按钮样式、评论插件选哪家这些细节换起来成本都不高实在没必要在第一次就选“完美答案”。我当时在主题配色上纠结了一整天如今回头看内容才是唯一重要的东西。5.2 我自己的选择决策公式为了把自己从选择漩涡里捞出来我给自己定了一个简单的决策公式对每个选项问三个问题——长期维护成本高不高如果选了这个以后每次升级、每次写文章要不要额外被它拖累。如果选错了换方案要多久半小时能换的随便选要花一个双休日重来的才值得认真研究。它跟内容本身相关吗这个选项能不能让读者更好地读到我写的东西。不能就往后放。按这个公式走很多选择就自动有答案了。比如主题和插件属于“换起来不算太贵”的项选个顺眼的先跑起来内容存储格式属于“换起来很贵”的项一开始就选通用格式。我不是说所有选择都要快而是要把纠结的时间花在对的地方。5.3 给还站在同一条起跑线的人的建议如果你现在也正准备搭自己的博客又在各种选择里转圈我作为刚趟过这片泥地的人有三句话想跟你说先确保从本地预览到线上发布的整条链路能跑通再考虑任何优化方向。链路通了后面每一步都是增量链路没通一切折腾都是空中楼阁。先写满三篇文章再回来换主题。当你有了实际内容对配色、排版、布局的感知会和对着空页面做选择完全不同——需求从真实内容里长出来而不是从想象力里长出来。勇敢地留下一些“未完成”。博客永远可以更好但发布一篇普通文章的价值远大于完美地打磨一个永远没上线的主页。选择困难症的解药不是找到最优解而是接受“足够好”然后带着这个版本往前走。回看这一路“选择困难”占掉了我大半的搭建时间但也让我把每个环节背后的原理摸了个透。现在博客跑起来了文章的草稿也排到了十篇以后我也不再为某个插件到底用它还是用它发愁。如果你的第一篇博客也卡在某个选择上记住我的体验先把那个叫“开始”的按钮按下去后续的每一个选项都会比你想象中的更简单。