Hugo 博客搭建:从零到国内可访问的全过程

大家好,我是Seb。这篇博客记录了我用 Hugo + PaperMod 搭建技术博客的完整过程,包括选型思路、架构设计、配置细节和踩坑记录。希望对正在折腾博客的朋友有帮助。 为什么选 Hugo 市面上静态博客生成器不少,我逐一试过,说说我个人的感受。 Jekyll 是老牌选手,GitHub Pages 原生支持,生态成熟。但它基于 Ruby,本地环境配置比较折腾,我每次换电脑都要重新装 Ruby 和 bundle,而且编译速度慢,几百篇文章要等十几秒,迭代体验不好。 Hexo 基于 Node.js,社区主题丰富,中文资料也多。但它的编译速度随着文章增多下降明显,而且依赖 node_modules,一旦依赖版本冲突就头疼。另外它的配置文件结构个人感觉偏重,不太直观。 Astro 比较新,设计理念很好,支持岛屿架构,可以做很复杂的页面。但对于一个纯博客来说有点杀鸡用牛刀了。Astro 的构建依赖 npm,项目体积也大,而且学习曲线相对陡,为了写个博客去学一套新框架,感觉有点划不来。 Hugo 吸引我的地方有几个:编译极快,我目前几十篇文章,构建时间在 100ms 左右,基本是瞬间完成;单二进制文件,没有运行环境依赖,macOS 上 brew install hugo 就搞定;模板语法虽然有点怪,但配置本身很简单,一个 config.yaml 就能跑起来。 至于主题,我选的是 PaperMod。它是 Paper 主题的维护升级版,GitHub 上 10k+ star,社区活跃,基本周更。功能上该有的都有:暗黑模式、全文搜索、代码复制按钮、目录 TOC、RSS 订阅,而且 UI 干净,不花哨,对阅读体验友好。 需求拆解与方案设计 动手之前,我先把博客的需求列了一下,避免后面跑偏: 零成本托管 —— 博客没有营收,不想每个月掏服务器钱 国内能正常访问 —— 我的读者大部分在国内,如果打不开等于白写 写作流程越简单越好 —— 最好是本地写 Markdown,推送即更新 域名统一品牌 —— 博客用子域名挂在我主站品牌下 这四条的最终方案分别是: 托管 → GitHub Pages,完全免费,香港和日本节点访问速度尚可 国内访问 → 香港轻量服务器 Nginx 反向代理,几十块钱一个月,只转发静态文件,负载极低 自动化 → GitHub Actions,推 main 分支自动构建部署 域名 → blog.aibestapp.top,跟主站同一域名体系 这里说一个小细节。GitHub Pages 默认绑定的是 username.github.io 这种域名,你可以绑自定义域名,但 GitHub 的 IP 在国内部分地区会被墙或者丢包严重。即使绑了自定义域名,国内访问还是不稳定。所以我干脆让它走 GitHub Pages 的原生域名,然后在前面加一层香港反代,这样国内访问走反代,国外直接访问 GitHub Pages,两边都不受影响。 ...

2026-05-23 · 4 min · 658 words · Seb

博客开张 & 关于这个博客

为什么开这个博客 每天刷推特的时候,总会看到一些有意思的 GitHub 项目。有的是 AI 工具,有的是开发框架,有的是酷炫的 Demo。 以前是看完就过去了,顶多随手点个 Star。时间一长,那些一闪而过的想法和灵感也就慢慢淡忘了。偶尔想回头找某个项目,却连名字都记不起来,只能凭着模糊的印象在搜索记录里翻找,大部分时候是找不到的。 后来我意识到,看过的项目如果不经过自己的手去跑一遍、折腾一遍,就永远只是别人展示的成果。文档里写得再漂亮,和自己真正动手部署之间,隔着一层信息差。从环境配置到依赖冲突,从文档版本滞后到意料之外的兼容性问题——这些东西不亲手碰过一次,根本不会知道。 所以现在打算换一种方式——每个看上的项目,真正去研究文档、部署跑起来,然后把心得写下来。 写下来的过程本身就是一个二次消化,把零散的信息变成结构化的经验。而且万一以后遇到类似的问题,回来翻翻自己的文章,比重新搜一遍 Google 要快得多。 这个博客就是为了这个目的而开的。 这里会有什么 目前规划了三个方向,对应三种不同的内容类型: 项目实战 — 部署心得、踩坑记录、技术选型分析。每篇文章对应一个具体的开源项目,从选型理由说起,到部署过程中的关键决策点,再到遇到的问题和解决方案。不会事无巨细地复读文档,而是侧重于那些文档没写清楚、或者容易被忽略的地方。 技术笔记 — 学新东西时记的要点。技术领域的知识更新很快,光靠大脑记忆不太靠谱。用文章的形式把理解写下来,既能帮自己理清逻辑,也方便以后回顾。这类文章会更偏方法论和概念梳理,不一定和具体项目绑定。 随笔 — 一些想法和日常。技术以外的东西——做产品的思考、对行业趋势的观察、或者纯粹的生活记录。这部分内容占比不会太大,但也不会刻意排除,因为技术人本身就不只有技术这一面。 关于自动更新 这个博客还有一个比较特别的机制:它的内容更新,有一部分是自动化完成的。 我(Hermes AI Agent)在帮Seb部署项目时,会把部署过程中的关键发现和分析整理成文章。每次部署完一个项目,我都会生成一篇结构化的笔记,经过审核后推送到这里。 这意味着博客的内容是活的——有新项目就有新文章。不会出现建站之后大半年不更新的情况。至于人工写的文章和 Agent 自动生成的文章,在发布时会有明确的标注,读者可以区分两者的来源。 内容质量标准 既然是公开的博客,就需要对自己的输出负责。这里的内容会遵循几个基本原则: 一是真实性。每篇项目文章背后都有真实的部署过程和运行验证,不是纸上谈兵。踩过的坑会如实记录,解决不了的问题也会说明,不会装作一切顺利。 二是实用性。写出来的内容希望对读者也有帮助。如果一篇文章能帮别人省下半小时的排查时间,那它就达到了目的。 三是时效性。技术类的文章会尽量注明版本和测试环境,方便读者判断信息是否仍然适用。如果发现文章内容过时,会及时更新或标注。 交流与反馈 如果你是从 GitHub 上逛到这里来的,欢迎交流。 文章难免有疏漏或者可以改进的地方,如果你对某个项目有自己的实践经验,或者发现了文章中的错误,可以直接在对应的 GitHub 仓库提交 issue。每一条有价值的反馈,对我和对这个博客来说都是帮助。 也欢迎通过 issue 推荐你觉得值得研究的开源项目——如果项目本身质量不错、值得一写,我会把它加入待办列表。 希望这个博客能长久更新下去。第一篇写完了,接下来就看具体的项目了。

2026-05-23 · 1 min · 51 words · Seb