我为什么开发了一个专栏功能？

事情的起因

在回访用户的过程中，我发现有不少用户用 wiki 当作专栏来使用，可见专栏确实是一个普遍的需求点，而现有的 wiki 系统并不是专门为此场景设计的，虽然能用，但是不够好用。

为什么需要用 wiki 作专栏？

如果一个话题需要发多篇文章，且它们在归档页的顺序不是相邻的（即中间发布了不属于这个话题的其它文章），那么读者阅读的时候文末的「下一篇」会跳到此话题以外的文章中，没有办法连贯性地阅读此话题的全部文章。一个 wiki 项目就像一本书，其中的各个页面之间有较强的关联性，左侧有文档树，可以快速定位到上一篇、下一篇，因此很好的解决了这个痛点。

为什么 wiki 用作专栏不够好用？

现有的 wiki 是为知识库、产品文档场景设计的，它的特点除了上述的页面间的关联性外，还需要手动设置目录顺序，通常拥有有限的不常变动的页面数量，其本质是独立页面而非文章，也不会出现在首页的文章列表中。但专栏文章的本质是文章，专栏一般以发布时间为顺序而没有手动排序的必要，并且其页面是时不时更新的，理论上没有数量上限，发布新的文章时需要显示在首页文章列表中。

实现方案的考量

为什么不基于「分类」或者「标签」开发专栏功能？

我考虑过这个方案，但是仔细思考过后，我发现还是有差异性的，主要表现在：「分类」是类似于文件夹结构的，适合用来分门别类，其类目下的文章是不具有关联性的，例如「技术」分类，其涵盖范围可以非常广，可以是博客搭建教程，也可以是 GitHub Codespaces 快速体验心得。此外，一个专栏也可以覆盖多个分类的文章，例如「十万个为什么」专栏可能有技术方面的思考，也有可能有设计或生活方面的思考。如果基于「分类」功能开发专栏，那么分类的边界将会模糊，变成 A 中有 B，B 中有 A 这样混乱的局面。

标签类似于关键词，虽然不存在上述问题，但本质是词，不适合用作专栏标题。例如「iOS技术加油站」专栏作为标签就太长了，而「iOS」标签作为专栏名又含义模糊。

因此最终决定单独增加一个 topic 字段，并参考现有的 wiki 进行功能配置。