把博客从易丢库状态迁到 Neon + R2：一次架构重做的完整复盘

内容摘要

一、问题是怎么暴露出来的 这次迁移不是“为了追新技术”，而是被真实故障逼出来的。 我原来的博客链路本质上是一个很典型的个人项目组合：前端放在 Vercel，后端跑在 Render，数据库先用 SQLite 顶着，图片也先走本地上传。刚开始这样做非常顺手，开发快、成本低、心智负担也小，适合先把博客跑起来。 但真正上线跑了一段时间之后，问题开始集中暴露出来：文章会丢、图片会失效、部署一改就容易把旧数据带没，甚至连“到底是数据库没了，还是只是当前实例没挂载到原来的文件”都不容易第一时间判断。最扎心的一次，是我回退代码版本、重部署服务之后，发现之前生成过的文章基本都不见了。 这时候我才彻底意识到一件事： 个人博客可以轻量，但不能建立在“数据和图片随时可能丢”的前提上。 二、旧架构为什么不适合继续跑 旧架构最大的问题，不在某一个服务本身，而在于“关键状态”放错了地方。 1. SQLite 放在不稳定运行环境里，天然有风险 SQLite 本身不是问题。对低并发的个人博客来说，SQLite 其实很好用，零运维、迁移简单、本地开发体验也很舒服。真正的问题在于：我当时跑的是 Render Free 方案，而这类环境并不适合承载需要稳定持久化的数据文件。 一旦容器重建、实例切换、部署过程发生偏差，\blog.db\ 这种文件型数据库就很容易出现“你以为它还在，其实你连到的是一份新的空库”的情况。表面上...