我的天

要把9000多篇文章，准确来说，是9498篇文章生成一个静态网站实在太难了。如果只是几天，哪怕是几百天，放在哪里，用什么表达，都不成问题，无论是哪个编程语言都可以做到，只是快慢有所不同而已。到现在为止，我已经试过三种编程语言了，首先是go，然后新都javascript，最后是python。

go对应的是hugo，hugo的建站速度是最快的，但快的代价就是电脑的所有性能都会被用到极限。生成网站的时候，CPU飞到顶，内存一直往上走，最后当我看到内存到达90%以上，CPU的使用率反而下降，说明已经到顶了。因为我在做建站服务器测试，那些虚拟的东西全部都放在内存里，显然，我8GB内存的小电脑没办法在某些模板之下，hold住这9000多篇东西，但并不是所有hugo的模板都做不到，有些简单的模板可以做到。另外一些，别说9000多，一两千，都很困难。具体反映出来的效果就是建站的时间很长，其次是内存封顶，结束时间遥遥无期。

第二快的是python。python是我的老熟人了。而生成静态网站，我用的是mkdocs。这是一个python脚本，但实际上脚本自己又调用了很多东西。所以你以为你只是装一个脚本就完事，但实际上你得连串装一堆脚本。只有几个markdown文件的时候，mkdocs建站是很快的，但没到达hugo那种秒杀的地步，但是就建站构成来说最简单的。初始化以后，会自动生成了一个配置文件和一个文件夹，你把markdown文件放到文件夹，然后建站，就可以看到网站的雏形，虽然那个效果肯定不是你想要的。配置文件只有一个，所以也没什么好让你发挥的地方。正是因为够简单，所以我觉得，对那些纯粹写作的人来说，而且，是纯粹写书的人来说，mkdocs这个东西要比hugo实在。但其中一个不友好的地方是mkdocs自带的搜索对中文不友好。搜索英文的时候杠杠的，但是中文就无能为力。如果丢进去mkdocs的文件非常多，到达几百几千的时候。你会很崩溃，跟hugo不一样，mkdocs的CPU的使用率永远只耗尽我其中一个CPU，所以CPU的使用率永远只是25%，至于内存，貌似我一直都没有看到变化有多大。生成一个几页的网站，需要几秒，生成一个200多页的网站，需要十几秒。但是生成一个2000多页的网站，却需要1000多秒。为什么会有这种指数式的增长呢？我觉得跟他们的搜索索引有关。总的来说我觉得gitbook和mkdocs的思路类似。他们会建立一个json文件。而那个东西我感觉就像是一个字典。之所以能自带站内搜索，就是因为他们建立了这个东西。读取写入其它文件，再怎么慢，也有个限度，而且是匀速的，但是如果要不断的增加字典内容，把新的文件内容全部写入到json里，然后存起来，这就很变态。思路很简单，但执行起来的时候相当费劲。

其中一个让其更加费劲的地方在于，但markdown文件非常多，就肯定有一个不断打开文件关闭文件的操作，还得递归某个文件夹里面的所有东西，想想都知道这有多累。但如果有个大文件，全部都已经结合在一起的话，就没有这个烦恼。之所以我有这种感觉，是因为之前我写了一个脚本，专门用来输出9498篇文章的标题与文件名，作用是造一个目录。当时我没有把脚本输出文件的代码缩进，结果仅仅输出目录，居然需要20多秒。目录很小，但是运行时间却跟我把全部内容都输出一样过。昨天我才发现缩进的问题，那就意味着每次增加内容，文件都打开写一遍。这就意味着那个文件被反复的打开关闭9000多次。紧紧减少一个缩进，等于把写入的次数从9000多变成1，于是那个运行时间就缩短为了6秒。读取一个二十几MB的XML文件并输出目录仅仅需要6秒。可想而知，如果不是频繁打开关闭9000多个markdown文件，而是直接用完整的一个大XML文件生成json，速度会相当快。那不就是跟字典类似的东西吗，简单到没朋友。如果我不想进行全文搜索，我只需要进行标题搜索，事情会变得更简单。简单到跟我生成那个目录没啥区别。

经过了这一番折腾以后，让我明白到明细数据与汇总数据使用起来真的很不一样，虽然就总量来说，二者是等价的。

接下来，或许，我真的会像网友所说，自己写一个脚本，把已经进行wordpress标准格式化的XML转为一个静态网站。

天下大势，分久必合，合久必分。这次我算是深切体会到了。

在没做过之前，不能觉得任何事应该会不太难，这种应该的想法会让你死得很惨。

静态blog的内容好了，模板也好了，但要放在那里托管呢？国内的没有备案肯定没门，付费的还得算流量。Gitee据说经常性习惯性宕机，本来我是倾向于CODING的，首先，那里要备案，其次，他们pages的服务器不在国内，于是非常有可能因为各种各样的原因，你还是访问不了或者速度很慢。网上提供了很多方案，但最多的还是GitHub Pages。我要玩静态blog，我要玩托管，我就应该从GitHub Pages开始。关于github这个东西，几年前我就开始见识过了，很多软件就是从那里来的，但到底要在哪里下载，在什么页面下载，我一直很迷糊。当时我并不明白开源的意义，所以下载回来一堆东西根本不知道怎么用。github上有非常多的用户，大家擅长的程序语言又各有千秋。开源的东西就是可修改但未封装，这就意味着我下载了一个不知道什么语言的脚本回来根本是用不了的。我不知道那到底是干嘛的，自然就不会去哪里研究。

我感觉GitHub Pages算是github给用户的一个自我介绍空间，github给用户免费空间和流量，允许免费托管的repo到底有多少个我什么都不知道，但用来撑起我的小blog应该没什么问题，毕竟我从来都不是个大流量的人。

不知道github是什么，不知道git怎么用，不知道为什么非得要用一堆命令行来解决问题。一句命令输入进去，有可能秒杀，也有可能屏幕开始跑马灯，因为我数据多，跑马灯可能要跑上几分钟。昨天做到最后步骤需要提交账号密码，提交数据的时候首先给我弹出的是窗口，但每次输入了都不行。接着就在CMD里继续让我输入账号密码。账号好理解，但密码的输入却是让我震惊。怎么输入都没反应，乱输一通也不行，我都怀疑是我电脑有问题了。后来才知道github的密码输入界面就是这样没有东西的，把密码输入完毕然后回车就行了。这么逆天的密码输入界面我还是第一次见识！密码等于是必须的盲打。经过这次以后，我脑洞里奇怪的知识又增加了。

网上教人怎么在GitHub Pages上用hugo做博客的教程很多，但当我真的要完全依照其中一篇实施的时候却发现到处都是问题。从安装hugo到虚拟单机测试这个流程我已经非常熟悉，通常这个部分都被讲得很详细，后续的怎么发布到github非常多的教程一句话带过。对那些本来就离不开git的人来说，那是简单到没必要说的事，但对我这个一片空白的人来说这是要了我的命！详细说怎么发布到github的教程也不少，有些甚至把CDN加速，自动部署脚本，域名绑定，双线部署等等高端的东西都说到了，但越是说得高端，越是会把小白最容易犯错的地方漏掉，比如新repo的文件名。有些教程看上去很有道理，但当你把那些语句复制粘帖的时候就会出状况，不是英文的地方用的居然是中文符号，在某些字体之下，那是很难靠肉眼分辨出来的，但贴到CMD里，那就铁定完蛋的节奏。教程写出来，一定程度就得考虑读者可能直接贴走，只能看不能操作，这到底算神马教程！

安顿好一切，那些我该懂的日常操作都懂了以后，我真心要亲自写一个小白教程！

数据太大，上传很慢，上传后网页打开很慢是我一直担心的东西，但原来这些我都想太多了，github上传数据的速度比我想象中快非常多。最终，我把静态博客部署上去了，并且绑定了二级域名。我的老blog终于合体后重新上线：https://yday.xlanda.net/，这里的链接叫做“青春无敌” XDDD

上周五我才开始研究静态blog。我选定的基本是hugo，因为这个东西生成网站的速度非常快。暂时我只是在本地操作。一开始的时候我不知道那个生成网站的命令窗口必须一直开着网站才能浏览，关掉的话就开不了了。之所以不了解这个，大概我还没研究过hugo的原理。之所以我在本地测试WordPress的时候可以一直开网站是因为虚拟的那个东西其实一直都常驻我的电脑。同样是本地测试，静态网站的生成速度以及网页打开速度比WordPress快非常多。如果只是几篇文章，生成网站的速度是毫秒级的，基本上就是一眨眼的功夫。昨天我测试了，生成200多篇文章的网站，也非常快，只需0.5秒。但是，如果网站有9000多篇文章呢，到底需要多长时间生成？这个我还没测试出来。因为我那9000多篇文章还没有完全符合的hugo框架的要求。

要用Hugo建立静态网站，如果是从零开始，当然很简单，按照他们的规则去写就可以了，但对我来说，我不是从零开始的，之所以用这个东西是因为生成速度快，而且可以挂在免费的空间上面。因为我的老blog很多，所以我必须要找一个这样的地方。如果我仍然使用WordPress，显然就非常浪费资源了。静态网站跟动态网站最大的区别，我觉得是静态网站不自带评论功能。几乎可以这么说，静态网站如果不外挂，是无法交流的。因为我挂的是老blog已经早就不去更新了，从前那些挂着blog的BSP都已经全部没了。我会在静态blog上留下可以交流的链接，如果有需要，访客可以找到我的blog，然后留言。这样的好处是起码你还能找到我，但坏处就是，你不能在你感兴趣的那个地方直接留言。去到我的blog还得解释你是从哪里来的，这就比较麻烦。但换个思路，我把那些已经不存在的东西重新又翻出来让你见到，其实已经很不容易了。

hugo的建站不难，但是如何把核心内容转化为hugo适配的不容易。我要把XML格式的大文档转化为一篇一边的markdown文档，这个星期我都在折腾这个。我本想直接用一个python脚本解决所有问题，因为理论上这是相当简单的操作，但是我却发现能搜索的python脚本，根本不适合我。有些已经老掉牙了，用的是python 2的版本，我试着转版本，让失败了，因为我实在不知道，里面的某些操作到底在新版本里是怎么个整法。

经历XML转化为另外一种格式的XML之后，我对XML这个东西算是有点了解了，我个人觉得输出markdown其实要比XML格式互转简单一些。XML互转只需要输出一个文件，但是markdown要生成无数个文件。python的操作之中，我最生疏的就是文件处理。输入输出那一章书我觉得自己根本没毕业。现成的python脚本无法满足我，我得自寻出路。幸好有一个叫做html2text python模块拯救了我，这个东西解决了从html到markdown的转换，所以正文最核心的东西的转化已经不成问题了，虽然里面还有一些说不准什么时候会出现的状况，但总体来说效果不错。XML的格式转化如果有一些我不想转义的东西，我还能用cdata把那些都圈起来，圈起来以后就没烦恼了，但是用markdown文件在hugo建站，必须有一个YAML的开头，而那个东西是有严格的格式限制的。篇名、分类和标签都必须严格符合这些要求。因为我的网址输出用的是python的时间戳，完全是数字，所以没烦恼，一开始的时候，文档的文件名我用的是时间加篇名，但因为片名的幺蛾子太多，所以，我选择了用纯粹的时间，单位精确到秒。如果不是手动设置过时间，不会发生重复。接下来我需要做的是整一套替换列表。把里面严格限制不让用的东西全部整理一遍。这样才能保证hugo的网站里能生成了我的全部东西，而不会有些不合规则的直接被屏蔽掉。WordPress没有这种烦恼，顶多出来的东西乱码而已，只要我把可能乱码的东西全部cdata。简直爽歪歪。之所以可以这样，是因为我把数据导入到WordPress的时候，软件默认把我不规范的东西规范化了，现在这个步骤，我完全得靠自己。

虽然现在我生成的文件还不能100%的符合hugo的要求，但从完全不会到可以生成，而且大多还是合格的，能做到这个我已经很满意。