我很早之前就一直在用 Hugo theme Stack主题 写东西。这款主题挺好的，但我觉得它更适合图片比较多的博客。而我现在的网站上面已经积攒了1700多张照片，在Stack主题的处理下，生成网站时会多出 7000到8000个文件！这就导致整个网站的仓库体积特别大，想部署到第三方免费平台（比如Cloudflare Pages）就变得很困难。

现在的问题很明确：我得换一个更轻便的主场，最好主要面向纯文字的。于是我在Hugo主题网站上找来找去，最后选中了这款叫Bear（熊）的主题。下载下来一看，这主题确实轻量，总共才几十KB，改起来也很方便。它本身是没有任何CSS的，只有最基础的HTML结构。不过我在实际用的时候，发现还是需要加点CSS的，就又对这个主题“魔改”了一番。后来又发现其实官方主题库有多个 Bear 版本，其中 Bear Cub 就带了 CSS，于是又换成了这个。

迁移到这个新主题的过程中，最难搞定的问题是我原来Hugo项目的文件组织结构。

我所有的内容，都是放在项目的content目录下面的。但这里边，我还分了两个文件夹：一个叫post，另一个叫posts（就是post加了个s）。之所以要分两个，最主要的原因是：文章数量实在太多了。如果都放在一个文件夹里，平常写东西或者整理的时候，很容易手滑把文件复制到错误的地方。我的策略是：把“已归档”的历史文章放在一个文件夹里（比如posts），然后新写的文章就放到另一个文件夹（比如post）。等post这个文件夹里的文章积累到一定数量了，我再手动把它们挪进posts文件夹去归档。这样用下来感觉就比较清晰可控，不容易出错。

另一个特点是，我原来的做法是：每篇博客文章的Markdown文件和它用到的图片都放在同一个文件夹里。比如写一篇叫《猫》的文章，那对应的路径可能是/content/posts/猫/，里面直接放着index.md、index.en.md（因为我博客是双语的）和所有这篇用到的图片（比如cat1.jpg）。

这种方式其实我自己觉得是优点：

1. 本地写作超方便：要插图的时候直接粘贴进来就行，图片瞬间就存到文章的文件夹里了。
2. 非常便于预览和管理：图片就在Markdown文件旁边，用任何支持本地图片的预览器都能直接显示。
3. 几乎不会丢图片：路径相对简单且固定，文件和图总是捆在一起。

结果换主题就撞墙了！因为绝大多数流行的主题，都默认使用“文字和图片分离”的模式——Markdown文件放在content/...下面，而图片统一放在像static/images/这样的目录里。可能是为了仓库管理更清晰或者缓存优化吧？但我就是觉得我原来那种“图片同目录”的方式更顺手方便。所以这次换主题，最大的挑战就在于：怎么让我原有的这套“图片同目录”的文件结构，能完美兼容新主题的需求？

这个适配过程……那自然是反反复复测试了很多次。最后我选择的解决方案是：把我存放博客文章的核心文件夹（也就是content下面那些post/posts目录们）做成一个Git Submodule（子模块）。

具体操作是：

1. 我把存放所有文章内容的文件夹分离出来，形成了一个独立的Git仓库（我们姑且叫它“写作仓库”）。
2. 然后我在主题仓库（无论是原来的Stack仓库还是新的Bear主题仓库）里，把这个独立的“写作仓库”作为Git Submodule引入。

这么做的好处是：

• 写作最简化：以后写新的博客文章、添加图片，我只需要在我的这个独立的“写作仓库”里操作就行了。它们天然维持着我习惯的路径结构（图文同目录）。
• 主题适配灵活：现在，我同时在用两套主题！原来的Stack仓库在用这个内容子模块，新换上的Bear仓库也在用这个内容子模块。这样，我只需要更新一次这个“写作仓库”，然后分别构建Stack和Bear两个主题的仓库，就能同时生成为两个主题适配的网站静态文件了。
• 便于使用图库：我已经将这个写作的仓库同步到Cloudflare R2存储，如果后续有需要，随时可以将整个图片设置成远程链接的模式，避免很快就用尽Vercel这类免费服务的资源。
• 为了解决两个主题仓库的自动化构建问题，我还给GitHub Actions那边的配置加了好几个工作流（Workflow），确保当写作仓库更新后，两个主题仓库都能被自动触发构建并部署。

选择现在这种“双主题并存 + 内容子模块”的方案，除了技术适配的考量，还有一个很现实的原因：我现在的阿里云VPS快要到期了。目前博客主要还是托管在VPS上，相对来说比较稳定、速度也快。但长远考虑，我很可能会把整个网站完全托管到Vercel或Cloudflare Pages这类平台上去。要把内容全部迁移过去，网站的体积就必须得尽可能精简优化。这次选择超级轻量的Bear主题，很大程度上也是为未来的这一步部署策略在做准备。