【博客】折腾记录
最近几天,折腾了一下halo和typecho,结果都不尽如人意,总感觉有哪里不舒服。兜兜转转,最终还是回到了现有的hexo解决方案上来。为了避免自己被服务器“绑架”,又把lsky的部署给下了,图床全部迁移到了对象存储上。
1.为什么放弃了halo和typecho?
本来,想更换到动态博客,就是为了避免自己再去部署一个图床。采用以大包小
的想法,避免自己服务器上部署太多“我自己觉得有用的”docker容器,白白增加自己的维护成本。
可真正了解了这两个框架后,才知道它们距离我心中的完美还有一定差距。
1.1 服务器
首先,最主要的原因还是因为动态博客框架都得需要一个服务器。
当下我活力旺盛,也有点闲钱来维护自己的爱好。但根据入坑以来浏览个人博客社群得到的经验,再加上对自己的了解,我估计到某个时间段,我加入放弃大军,让自己的博客陷入不维护的黑洞。
这时候,免费的解决方案就很有必要了。
这也是hexo这类静态博客框架的最大优势之一,光是可免费部署的平台,我个人知道的就有5个以上,这其中还包含了不太可能会停止免费的github pages
。这么多平台,足够你将hexo部署多个备份,哪怕最终不维护博客了,旧的博文也不至于失联。
1.2 编辑器
typecho和halo1的编辑器还算可以,但halo2就让人很是无语,它竟然只有一个富文本编辑器,而且还不支持导入MD文件
,复制进去的MD内容也无法正常识别!
这给我惊住了,作为个人博客的框架,难道不应该第一时间考虑MD编辑器而不是富文本吗?
虽然halo2路线图中明确表明了会加上md编辑器,但现在没有就是没有……我几百篇文章,总不能一个个重新敲一遍吧?
这里就要表扬halo1了,其自带了一个可以导入hexo的md文件并自动识别frontmatter里面信息的工具,还算是给迁移提供了一点方便。
编辑器的问题暂且不谈,毕竟这是一个可以克服的困难,下面来说说更新问题;
1.3 更新问题
使用hexo的时候,我可以将自己本地的更新push到github上,由vercel/netlify/github-action自动部署为hexo博客。
git一次,就能够更新多篇本地有更改的文章。
而使用动态博客,包括CSDN,如果对旧的博文有修改,就必须要去博客后台的编辑器修改……而我个人对任何博客,准确来说是任何平台的在线编辑器
都不报信任。一次网络波动,就可能让你几小时的心血清空。除非其能提供类似金山文档
的自动保存多份历史版本的功能,不然看上去人畜无害的自动保存草稿
功能,也照样会欺骗你。😭 这点就不深入展开了,体验过的人自然懂我在说什么。
自那以后,我就把自己的所有博客从在线编辑迁移到了本地md,并配置了自己的图床(刚开始用的阿里OSS)。
HEXO能直接和本地MD对接,我想修改什么,只需要修改本地,push到云端。
而使用动态博客,就会出现我很不喜欢的多端同步
问题。而halo和typecho编辑器的不突出,会让这个问题更严重。其让我还是想用本地编辑器去写文章再上传,而这又得让我去部署图床(不在博客框架的编辑器里面写,图片还是不能上传到服务器本地)那这样下来,感觉和用CSDN没啥区别了……
上面说的感觉不是很清晰,列个表吧。
动态博客更新流程
理想流程如下:
- 在动态博客后台写博客,写完即更新
- 图片上传到博客服务器后台
- 出现需要修改的,也是直接在后台修改
实际由于动态博客后台编辑器体验实在是大不如本地,导致我还是想用本地编辑器写文,这就导致流程变成了下面这样
- 在本地typora编辑
- 图片通过picgo等工具上传到图床(然鹅并不能上传到博客后台)
- 写完后,打开博客后台,复制粘贴更新
看上去并没有特别麻烦,但这样会出现一个附加的问题:
- 由于图片不能直接上传到博客后台,你需要额外配置一个图床
- 自建图床?服务器内存
-300mb
起步;本来1h1g就能跑博客后台,这下被迫升级2g,钱包--
- 使用OSS?得提防恶意刷流。
图床并不是我讨厌的问题,我讨厌的实际上是下面这种情况:
- 假设我有一篇文章A,该文章引用了文章B
- 由于发现A有误,我来修改A
- 修改A的过程中,发现引用的B过时了或者也有问题,顺便修改了B
- 此时我需要更新到博客
- 上博客后台,我需要
搜索A和B
,然后复制粘贴更新
HEXO博客更新
然而,如果用HEXO,此时就只需要执行两个命令,就能立马更新博客
1 | hexo cl |
这其中,如果没有修改博客配置文件,hexo cl
都可以不用执行;
在同时本地修改了多篇博客的情况下,显然是HEXO更方便一键更新博客;
剩下的下次有时间再写吧……
本文记录的仅为本人的观点,不同人使用习惯不同,并没有抨击动态博客的意思,请不要误解!