我是如何搞砸了本站搜索服务的
上一篇简单提到，我上线了本站的站内搜索服务：Algolia，本来还写了有一些些的，然而，由于我所使用的 Markdown 编辑器 Typora 的问题，在我主动按下 Command + S 的时候有较高概率会触发崩溃（按照默认的设定直接关闭文件就是自动保存，可是人总是想更保险一点是吧，可结果……），所以，当时崩溃又写了些，写了些又崩溃，然后又写了些，又崩溃，又只要仓促写了些，毕竟大半夜的还是要睡觉的。
Typora 最近又更新了好几次，刚还遇到不能回删文字的情况，可能还是系统兼容问题吧，希望工程师们能有精力尽快完成修复了。
今天，我有意识控制不去按 Command + S，其实在 macOS 的逻辑里，好多的软件都默认是自动保存的，不过还是有一些不是，这使得习惯还是会有些些分裂，要是厉害了，还是有可能导致精神分裂的。
还是谈今天的主题：我是如何搞砸了本站的搜索服务的
上线了搜索服务后，搜索体验在所有遇见过的站内搜索中，算是顶级水准了。
从产品来看，这个搜索服务的所有操作体验应该是完全没得话说的，后台漂亮，数据清晰，API 工具所提供的接口也及其清晰明了好理解，文档更是做的非常好了，我这个英语渣整篇看下去完全没问题，偶尔几个不认识的单词，用下 macOS 系统自带的词典，选中单词就查得到中英解释。
但是，要说这个产品在国内的被使用情况，真不咋样普遍，为啥呢。
首先来说，它真的就是专门做搜索外包服务的，SaaS 模式，提供一个服务解决方案给你使用，直接靠这个产品本身来挣钱的，跟谷歌这类性质完全不一样。也就是说，它其实是个付费接入才能使用的服务。不过我这里不用担心，它同样有一个免费的方案 COMMUNITY Plan 提供给我们这样的普通小站用户，可存储一万条记录，每个月有十万次操作数可供增删改查使用，对于咱这样的小站来说，目前及未来可预见一段时间内，完全足够了。
它还有个特别的服务：DocSearch，用来干嘛的呢，一般人看名字看不明白，程序员可能一眼就理解了：用来做“文档搜索”的，什么是文档，就是大多数时候被称作 Documentation 类似这样的东西，就是差不多是“说明书”的意思了，一个工具如何去正确使用，是怎样的设计理念，有哪些问题需要解决，未来如何发展等等。
DocSearch，这个东西，免费提供的，最简单的使用方式：提交你的网站，通过了，它便帮你建立索引，然后会告诉你如何接入搜索功能，这样，就能有了搜索服务了。不过，我的理解应该不是所有网站都能被索引，应该仅限于互联网技术类文档吧，毕竟从列出的例子来看是这样的。
个人博客这样的小站还是自己折腾下吧，自己的东西不拿来折腾，还要拿谁的来玩呢。
本站是免费托管在 github.io 上，这是要让你知道的。自然地，上一版用来构建本站的工具就是使用的它官方所支持的 Jekyll 来处理 Markdown 文件来构建博客内容。
使用了配套的由 Algolia 官方推荐的索引工具 Algolia for Jekyll，就这样，上一版就这样成功地实现了搜索服务。
但是，为什么要有但是，就是因为其实在程序员的世界，永远不会满足于已有的工具，最开始用的好好的，但凡是发现了新的工具或者是原有工具遇到了根本性的痛点，转身离开的样子是绝不会回头半分的。
是的，我发现了 Hugo，基于对 Go 语言有一些些道听途说的好感，也测试了 Hugo 的运行情况，认为完全有必要用它来替代目前的 Jekyll 来处理这个站的内容。
就这样，我把构建工具切换到了 Hugo，重新研究了模版的设计，又原模原样地利用了已有的资源搭起来了这个小站。
等搞定一切最终发布到线上之后，问题终于来了：搜索服务没一个点进去能看的，文章 URL 全部失效了。
第一步：更新索引，有找到 hugo-algolia 与 atomic-algolia 这两个看似配套的工具，尝试用 hugo-algolia 去建立新的索引内容，清空原有索引 - 成功、添加新索引 - 失败，数据就这样没了。hugo-algolia 所报出来的错误我也完全无从查起，搁置。也没心思去研究 atomic-algolia 了，pass。
第二步：恢复索引，切换到原有 Jekyll 分支，重建索引，报错，因为还是多了很多文件的，具体不细究。还好更新到 github.com 之前先下载了备份，用它重建索引，完成。
中间还有一些其它的尝试操作，就不细叙了。
所以，现在还是首页依然所有搜索结果的 URL 是点击不了的，而菜单页入口的文章列表也还有些问题。
为啥页面看上去如此简单，因为不熟悉这个新东西的话，保持最简单的可运行实现，是建立一步步继续研究信心的关键，而页面设计恰恰并不是我所擅长，所以暂时就照原有最简单的实现吧，何况我也喜欢简约风格。
现在写这篇文章之时，它的搜索服务依然是无法完整地正常使用的。
接下来的打算：
- 无论是 Algolia for Jekyll 还是 hugo-algolia 与 atomic-algolia，逻辑上均应是利用 Algolia 的 API 工具操作数据，目前已测试 Python 版的 API 工具，基本情况都了解了。
- 无论是利用 Jekyll 或者 Hugo 别人写的工具来更新数据，均存在不合理的地方，特别是 hugo-algolia 可能仅仅是个半成品差不多，而我并不想去提 PR，毕竟非我所熟悉的语言领域，所以考虑的一个方案就是自己写个小小工具专门配套我的内容建立索引，毕竟 Python 开发起来并不难，前提是想清楚方法和细节。
- 说不难，也还是有写难度的，如果这小工具做好，感觉利用 Python 处理 Markdown 生成静态网站页面的内在知识也应该翻的差不多了，可能到时候又会有新方案？
- 虽然还有个方案是修改 Hugo 的配置和模版来修复 URL 问题，但是我不想了，看上的就是 Hugo 的 Markdown 文件管理模式，要走就走的彻底些。
- 细节就不絮叨了，大概如上。
毕竟是自己的小站，访问量几乎可以忽略不计，功能简单随便玩，只要不全挂，我就还会整更好的。
深入研究某个东西，是个及其耗时的操作，而勉强搭建起来可以跑，只是蜻蜓点水，对成长没有助力的。
而心却慌慌。