我的天

要把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转为一个静态网站。

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

昨天花了一个晚上研究aria2，好不容易在睡觉前之前研究通了如何在Firefox里直接调用Flashgot然后在Aria2 WebUI里开始下载，而不是弹出aria2的命令提示符窗口。我以为一切都已经解决了。同样的配置，同样的文件拷贝到单位的电脑上却无论如何都无法还原。难道这是Win7 32位和64位的区别？以前不知道，但在我用过Win7之后就明白到其实64位的系统32位的程序其实还是可以兼容的。aria2的配置是一样的（里面和绝对地址有关的东西都已经改过来鸟），aria2的确有32位和64位之分，但我两个都试过了。WebUI没有32位和64位之分，我放在坚果云的同步文件夹里，而且那个东西里面也不存在什么设置，所以是一样的。唯一我觉得有可能不兼容的就是网友利用aria2rpc以go编译出来的exe文件，那个文件在64位的系统里会失效？否则真的无法解释为什么同样的Flashgot设置一个能成功调用一个不行。因为参数模板是一样的，可执行路径都指向已经编译好的aria2rpc，这些不会出错。在Flashgot里直接调用命令行的aria2是可以下载的，在Aria2 WebUI里添加链接也是可以下载的，但通过Flashgot就无法成功调用Aria2 WebUI，郁闷！如果已经编译好的go行不通，非常有可能就要用需要运行环境设置的py。为了一个超轻量级的下载器这般来有点儿过于劳师动众了。

家里的电脑可以用Flashgot调用Aria2 WebUI下载，而且通过那个传输过去的文件名不出错。单位这台电脑无法通过Flashgot调用Aria2 WebUI下载，如果把百度云的链接手动贴过去文件名会乱码。而且今天的测试证明文件也下载不完全，其中原因不明。文件名不对还可以接受，但文件下载不完全这个问题很严重！Aria2 WebUI界面显示文件已经下载成功，但实际上播放器却不能播放，这简直就是浪费感情啊！在没有折腾出个所以然之前，单位这台电脑只能通过命令行的界面控制下载，开始下载很容易，如何终止呢？直接关闭窗口吗？而且如果Flashgot直接调用aria2除非我在参数模板一个用上代理设置一个不用，否则下载开始后就没办法再回去了，下载之前就得想清楚。其实有点我想不明白，既然aria2已经有配置文件，为什么Flashgot的设置界面还要写那一大堆参数模板呢？那堆东西是传输给谁的呢？如果写那一堆东西可以传递给Aria2 WebUI，写那些也都值了，但如果在Flashgot里直接调用aria2c.exe文件会直接跳出命令行界面，但Aria2 WebUI那里却没反应，为什么我还要写参数模板？因为我也曾经试过路径用aria2c.exe，参数模板只写[URL]也一样可以正常下载。

360倒下了，QQ旋风倒下了，迅雷再也不支持离线和高速通道了，我们就只能吊死在百度云那里。是时候找一条新路了！