如题，在五月底，承载我博客系统的云服务商（狐蒂云）跑路了。它毫无征兆地直接关机销毁了一批云主机实例，而我正好被波及。
而因为我近期并没有怎么关注我的博客，没有提前备份，恰逢三月底时我的笔记本进水导致硬盘烧毁。两者夹击让我丢了不少博客存档。那批博客没有被推送到 github 存档，只是本地写完后，直接上传到博客系统。于是晚安与她皆失。
目前通过备份捞回来的只有到 2025 年三月的部分，最近的一篇是关于仙逆与凡人修仙传中的化凡。不过说起来，我竟然因此松了一口气，因为那是我心平气和写的最后一篇类似于观后的东西。
我以前写过：没有记录观后的日子过去后就好像完全消失了一样，毫无痕迹。
这一年就好像这样。后来写的都是些啥，Attention is Limited - Lost in the Middle，单图≠多图：多图理解时 VLM 为什么更容易”胡说”，以及一个两阶段解法。但讨论是否值得被记录前来先回顾一下个人博客的形态。
博客形态
依赖云平台
博客园无论从观感还是自由度来说都是极好的，比起某 CS 要好非常非常多。
但如果讨论起形态，它展示的文章数据位于平台，而存档通常都得依赖用户自身备份。存在本地-平台数据不会自动对齐的问题。用户如果跨设备同步很麻烦，需要借助一些中转设备或者云平台。而如果存档的设备突然坏掉，那么备份没法快速从云端恢复同步到本地。
同时还有的一个隐患就是平台本身的一个存续问题，先前就有博客园要倒闭的情况。
而经营较好的 CSDN，我觉得你也不想别人在看你写的东西时旁边跳动着广告，或者下面突然弹出来付费解锁，或者登录查看全文吧。
我仅仅只在 CSDN 上发过一个 .condarc。但它的阅读体验（碰到有点东西的文章发现还是搬运自博客园或者其他平台的）和搜索时总是让它位于前列让我对云平台的观感都差了很多。
依赖个人云服务器
我使用了两年多。
我最初部署的是 NBlog: https://naccl.top/
后来部署了 Shiroi: https://innei.in/
两者都是前后端分离的。这会需要一点门槛，cors 跨域以及前后端分别运行如果没有对应 docker 镜像会有些棘手（特别是不熟悉使用的框架）。
它和博客园同样存在的问题是：
所存档的源数据和上传到博客系统里的数据并不是完全一致的，很难互相转换。很难从本地数据还原成博客形态（一篇一篇重新上传），也很难从博客形态还原备份到本地。
后者 Shiro 做了所有文章导入和导出的功能。支持同博客系统内，把先前的博客数据导出并且再导入，在迁移服务器时会有些用。但是它天然不兼容其他博客系统，而且存档文件人类不可读，不能用作本地存档。所以它其实很鸡肋，也许正因为这点鸡肋，作者的导入系统做得也有点小 bug，没有向旧版本兼容，我当时被迫手动还原了每一篇。25 年 React 重大安全隐患时，我的博客中招被迫重装系统，但从旧版本导出备份文件，无法被新版本解析导入 =-=，两个版本大概隔了半年。
WARNING而且维护个人博客除了服务器成本开销外，最恐怖的就是被服务商跑路背刺。数据丢了就是丢了，想找都找不回。当时我记得就是因为 React 事故，我从腾讯云暂时转移到了狐蒂云，但我事后因为迁移困难就没有再次迁移回腾讯云。构建 Shiroi 是真的不容易，包括回放完数据后我根本没有精力做额外备份，环环相扣。
在使用这类博客的过程中，通常我也会把博客推送到 github 的某个仓库做存档，但是这个推送习惯很不好，有时候是没写完得等写完，有时候是感觉不值得推，有时候是 github token 过期了再拖一拖就忘了，而且创建的文件有时候用年月做文件夹分隔，有时候年月文件夹忘记创建了所以几个月的文件都挤在一个月的文件夹里。
可以说管理得让我看了都心里交瘁。但是我又不好直接删库。即便反复整理，也会再后续使用中熵增。而且最大的问题是，为了克隆时速度更快文章和图片分在两个仓库里，用 jsDelivr 的链接引用（PicGo 上传）。这导致另一边的图片更是恐怖。
依赖 github pages + 工作流部署
这个博客是由一个 github 项目的 workflow 直接构建后 push 到 github pages 形成的。
它有几个优点：
TIP
- 随时拉取整个项目，里面包含所有的，规划清晰，命名合理的博客源数据，它是 markdown 格式的，和用户刚刚写时一致，即便要迁移或者阅读都不成问题。
- 不需要经过前端部署，后端部署等复杂操作，只需要域名，dns 即可，配置好后所有构建、更新工作由 workflow 自动完成。
- 项目即是博客，更新即时存档，同步即可备份。除非 github 倒闭或者 pages 或 workflow 的使用策略发生变化。
对于我而言，它最重要的就是消除了我原本一直保持恶劣更新习惯的 Blog 和 Blog_Image 两个仓库。
SigureMo 佬一开始就是用这个方案，我记得我在 NBlog 时期加了佬的友链，如果早些入坑就少走许多弯路。
这个博客足够简单，让我可以更专注地去写博客，同时不需要烦恼 commit 推送的时机。
我记得我在换到 Shiroi 之后，虽然博客系统漂亮复杂了不少，但是我反而写博客的频率少了许多，有些可惜。
值得被记录的东西
和观后那种感受和情绪的抒发不同。
如果偏向技术类和教程类等学习过程中产生的博客（为什么说过程中，因为我习惯边写边学，很刺激，当我学完后的总结反而是索然无味的。）很多时候都比较初级，甚至谬误不少，我习惯边给出猜想边验证修正它，而很多时候等我修正了思路，可能会漏过存量的修复。
我问过我的自然语言处理的老师他是否写博客（因为很多时候他讲课的方式给人一种写博客的思路的那种感觉，而且跟我一样非常容易扯歪）。他说他写过几年，但后来不写了。
我追问原因，他说是因为回看早期写的文章很多都是错的，幼稚的，不够深入的。而秉承着不传播错误的原则，就封笔了。
确实我现在的视角去看以前写过的 uv 使用指北，或者 pyqt 学习日记，这些尤其强调从零开始的博客，对我来说它真的过于初级，毫无益处，甚至能找出不少言语表达不当的地方。
我仅仅只是想想有一个初学者恰好看到这里要被我这个曲解官方文档的说法误导，或者一个精于此道者正在看我写的那篇入门日记，我就会尴尬的无地自容。
我以前通常避免读这样的博客，而这次存档丢失正好让我摆脱了它们，反而让我松了一口气。
我不得不反思，像那样的博客是否还应该继续写？是否应该毫无审查地就发表到公共区域？
边写边学让我能够有更深的印象，不管是对的还是错的更深，纠正的过程让我真正理解得更深。但最终真的理解对了与否，应该给大模型审查一下再说。
我也在这里划分一下值得记录的东西大致分为几类。
NOTE
- 资源分享类别，通常不涉及具体知识传播或者思考内容，只是纯粹地给别人推荐一些渠道，应用，信息。比如找书，找漫画的网站之类。
- 观后，这类作为回忆展柜以及同类诱捕器依然值得继续构建。
- 教程，流程类记录。比如记录我开发的某应用的使用教程，或者什么软件的使用教程，比如老滚五的 skse 启动，动作数据刷新，调整身形，mod 排序等等。
- 思考，由某件事或者某个物而产生的更深层的思考。以及思考所引起的一系列操作。比如发现网页端 LLM 多图识别支持八张甚至更多都能良好区别特征而本地 api 调用超过四张就开始说胡话。这个思考不一定分清对错，但是让我自洽。
- 边写边学。应该给它打个 useless 的标签，无营养的探索过程，如果读者实在没找到合适的教程案例也许可以在我的探索过程中找到想要的东西。当然，同样不一定对，只是自洽，但我会让 LLM 进行审查。
