最近几天，折腾了一下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 2	hexo cl hexo g --d

这其中，如果没有修改博客配置文件，hexo cl都可以不用执行；

在同时本地修改了多篇博客的情况下，显然是HEXO更方便一键更新博客；

剩下的下次有时间再写吧……

本文记录的仅为本人的观点，不同人使用习惯不同，并没有抨击动态博客的意思，请不要误解！