Hugo 对我而言还是比较难

月初把这个博客的系统换成了 Hugo 之后，逐渐习惯了一些操作，可以正常的发布文章了，但仍然感觉用着不是百分百顺手。

一个是近期发现，原本配置好的归档页面不灵了。周末的时候检查了一下，同样的博客仓库，在 Linux 下生成文章，归档页面就是一片空白，在 macOS 上生成就是正常的。我还没有深入的去查找问题，只是凭直觉感觉挺奇怪，按理说不应该，除非跟 Hugo 的版本有关系？我之前在 Arch Linux 环境下也有这个问题，Arch 下的软件包应该都是最新，也不应该会出现更新不及时的可能性吧？

另一个问题是，我上周在 Inoreader 里订阅了自己的博客后，才发现默认的 RSS 输出是摘要输出，我一直比较讨厌 RSS 摘要输出，结果自己的博客也成了摘要输出，让我有些尴尬。于是我咨询了 DeepSeek 和 Kimi，找一个解决方案。最终在刚刚，终于实现了我我希望的 RSS 全文输出最新 20 篇文章的想法，也带来了我这篇文章的感叹——Hugo 实在是太复杂了。

“复杂”一词是一个综合性的描述，我实际的感觉，主要是“零碎”，说好听点是“灵活”。Hugo 不愧是最初给程序员开发的博客系统，远非给普通人用的博客系统，比如 WordPress、Typecho 那些好配置。哪怕到了今天，我刚查了一下，自 2013 年公开发布，Hugo 已经有 12 年的历史了，它还是只做最基础的功能。一些额外的功能，都属于定制化的，而定制，就有很多种方法了。

一个例子就是主题。按照我最早天真的想法，对博客的基础信息做好配置后，想要换个主题，就是把主题拉下来，然后在配置文件里改一个变量就可以了，结果不是这样。每个人开发的主题，有自己的变量命名习惯，也分别实现了不一样的功能，导致你配置好了一个主题下的展示界面后，换一个主题有可能会很糟糕。以至于我现在只敢用一个 Mainroad 主题，还不敢换其他的。而且，安装主题还有不同的方式，最诡异的是点一个链接就能生效，给我的感觉是 Hugo 的配置又简洁又复杂。很多主题都给出了 Hugo 的核心配置文件的示例（就是 hugo.toml 文件），假使核心配置文件里的配置可以抽象出来，那何必要主题来给出示例呢？

另一个例子是今天配置 RSS 全文输出。我配这个不是第一次了，上周我就按照人工智能的答案进行了操作。有的操作很优雅，在核心配置文件里加上两行就行。我一开始就是那么做的，结果获得了摘要输出。再想搞全文输出，我本以为直接加一个变量，告诉 hugo 我想全文输出就可以了，结果无效。问了 AI 几次后，验证有效的结果是修改主题文件。这还不是最终结果，按照 AI 最早给的答案，输出的只有我创建的单独页面，而不是我普通发布的博客文章。后来给的答案，我看用了个笨一点的办法，直接遍历了所有的文章，造成输出的 XML 文件巨大，时间也巨慢。无奈再次询问 AI，给加了一个 range first 20 语句，算是达成了目标。但全部文章的内容已经保存在了变量里，只在输出的时候取了前 20 个。我想也就是 Go 语言的运行效率高，不然这里的时间复杂度要爆表了。

灵活性带来的副作用，就是没有标准答案。TIMTOWTDI 对写程序的人来说是免于束缚的宣言，对读程序的人而言就不是那么友好了。特别是当我的老师是 AI 的时候，常常会信誓旦旦给我一个方案，我尝试后告诉它不行，然后它又非常自然的给我另一个方案。因为不确定这个方案是否可行，所以我也不会在操作前进行记录。最终结果是我到最后也搞不清楚哪个方案生效了，只是稀里糊涂的保留一个 Git 仓库，期望历史记录可以给我多点线索。对于把过程记录下来，以便将来研究，我比较悲观。

网上真的有厉害的人，可以把 Hugo 博客配置的比较复杂，我还远远达不到这个程度。Web 前端也是我的弱项，CSS、DIV 这些看得我头疼。好在我基本上了解了 Go 语言，或许哪天我应该研究一下 Hugo 代码，也许会有所帮助吧。