Mdbook

在数字内容创作的旅程中，工具的选择往往折射出创作者在不同阶段的诉求。从最初的小程序“豆子碎片”，到尝试使用 Rust 生态的 mdBook，再到最终回归并定于 Hugo，这不仅是技术栈的迁移，更是我对内容分发、用户体验以及商业化潜力深度思考后的结果。 1. 痛定思痛：告别移动端封闭生态的束缚 最初，我将大量的笔记和技术心得打造成了一个名为“豆子碎片”的小程序。初衷是利用移动端的便捷性，但随着内容的积累，弊端逐渐显现。 最直观的痛点在于性能与体验。小程序在渲染长篇幅的技术文章，尤其是包含大量代码片段的内容时，卡顿感非常明显。更重要的是，作为一名开发者，我发现小程序在内容搜索与社交分享上存在天然的屏障。技术内容应当是开放的，它需要被搜索引擎检索，也需要方便地在网页端被阅读和引用。 为了打破这种孤岛状态，我决定回归网站博客。 2. 抉择：为什么不是 mdBook？ 在回归 Web 的第一站，我首先关注到了 mdBook。作为一个偏爱简洁风格的开发者，mdBook 这种类似文档流的展示方式起初非常吸引我。然而，在深入使用并尝试进行定制化开发时，我遇到了一些瓶颈。 扩展性的局限 mdBook 虽然在文档编写上非常纯粹，但在作为通用博客平台的扩展性上显得略为乏力。由于它主要为 Rust 文档设计，当我试图通过编写插件来处理一些特殊逻辑时（例如将我在小程序中定义的私有格式 type|url|params 自动还原为标准 URL 链接），开发过程并不如预期般顺遂。 技术栈的契合度 作为一名后端开发者，我对 Go 语言 拥有更高的熟悉度。在折腾 mdBook 插件遇到阻碍后，我意识到：用熟不用生不仅是开发经验，更是提升生产力的核心。 3. 回归 Hugo：灵活性与商业化的平衡 最终选择 Hugo，是我在权衡了扩展性、性能与长期维护成本后的决定。 强大的扩展能力与 Go 生态 Hugo 作为基于 Go 语言构建的静态网站生成器，其渲染速度堪称业界天花板。更重要的是，它的模板系统极其灵活。对于我之前在小程序中定义的自定义链接格式，我可以通过 Hugo 的 Shortcodes 或正则表达式替换轻松实现自动化转换。这种“随心所欲”的控制感，是后端开发者最看重的。 布局与精力的分配 在经历了几年的技术折腾后，我悟出了一个道理：开发者的时间应该花在内容创作上，而不是无休止地调整 CSS 布局。 我选择了 PaperMod 主题，因为它精准地命中了我所有的痛点： 极致简洁：没有冗余的装饰，让读者聚焦于文字。 响应式设计：完美适配手机端阅读，填补了告别小程序后的移动端体验。 易于 SEO：内置了完善的 SEO 结构，为后续的流量增长打下基础。 4. 商业化的考量：为了 Google AdSense 之所以选择 Hugo 而非继续留在 mdBook，还有一个非常现实的原因——流量主申请与广告布局。 ...