敲下最后一行 Commit 信息，git commit -m “feat: finalize decentralized storage logic”。这个十年博客计划，技术上算是画上句号了。不是结束，是它终于能自己跑了，不用我再像2019年管团队那样，天天盯着服务器怕它崩。去中心化，说白了，就是“别把所有鸡蛋放一个篮子里”的技术版，但实现起来，每一步都是对过去十年踩坑的报复性补偿。
2016年刚开始写博客，用的是WordPress，租了个最便宜的虚拟主机。那时候对“存储”的理解就是FTP上传，备份就是手动把数据库.sql文件下载到本地硬盘。结果有次服务商跑路，数据丢了小半个月，急得我满嘴燎泡，从百度快照里一点点扒拉回残缺的文章。从那时起，数据安全感就成了心病。后来自己撸Python爬虫做SEO，见识了各种网站的DOM结构，也见识了服务器说挂就挂的脆弱。所谓中心化，就是你寄托信任的那个点，无论是服务商、某个云平台，还是你自己的那台破服务器，它本身就是单点故障。
所以这次最终版的逻辑，核心就三块：源文件、渲染引擎、存储层。源文件就是所有Markdown文章和配置，用Git本身管理版本，这是基石。渲染引擎是我用Go重写的一个静态生成器，极简，快，本地运行，生成纯HTML/CSS/JS。最关键的是存储层。我设计了一个分发脚本，核心逻辑不是“上传到某个地方”，而是“同步到多个互不信任的地方”。
具体流程是，本地渲染生成整站静态文件后，脚本会同时做几件事：通过S3兼容的API推到Backblaze B2（便宜，冷存储可靠）；通过Rclone同步到一台我常年开着的、放在朋友机房的旧NUC小主机（物理分散，另一个城市）；通过Git推送到GitLab和GitHub的私有仓库（利用大厂的冗余和版本）；最后，还会通过IPFS的pin服务，把整个站点目录的CID固定到至少两个远程Pin节点上。脚本里用n8n编排了这套流程，但最终封装成了一个单文件CLI工具，`flovico deploy`，一键触发。
这里面的“去中心”味道在于，这几个存储位置彼此独立，没有主从。B2挂了，还有Git仓库；GitHub抽风（不是没可能），还有IPFS的CID能通过公共网关访问；就算所有远程服务都出问题，我朋友机房那台NUC只要能联网，就能拉起来一个完整的站点。访问逻辑也做了降级：主域名CNAME指向B2的CDN；备用域名指向GitHub Pages；还有一个IPNS地址记录最新的IPFS CID。用一个轻量级的JS放在首页，检测主站加载失败就提示用户切换备用入口。
这根本不是技术上的最优解，里面有大量的冗余和一点点浪费。但这是一种心态上的治愈。2021年断尾求生，从团队交付里逃出来，我就明白一个道理：把自己绑死在任何一个单一系统上，无论是技术栈、客户源还是收入渠道，都是危险的。现在的AI自动化教练工作也一样，我的知识体系、交付物、客户案例，都通过类似的逻辑在多平台分发。不再有“唯一真理源”。
十年前，我焦虑的是技能会不会过时，爬虫会不会被封。五年前，我焦虑的是团队明天会不会有人离职，项目会不会烂尾。两年前，我焦虑的是大模型会不会让我整个技术栈归零。现在，我焦虑的是如何让这套自生长的系统，在我不再频繁维护的下一个十年里，还能被访问。这套去中心化存储，就是对抗这种终极焦虑的物理手段。它不酷，甚至有点笨重，但足够可靠。
Commit推完了。这个博客项目，从此它的生存概率，不再只依赖于我的记忆力和维护热情，而是被分散到了几个大洲的服务器硬盘、分布式网络的哈希里，以及那台嗡嗡作响的旧NUC里。我可以放心地，让它自己去面对时间了。
