一个个人博客真正的瓶颈不是性能，是维护成本。

我有一台 2 核 2G 的云服务器，只想放一个个人博客。需求很简单：写文章、有后台、能配图、偶尔有人访问。围绕这个目标，我最后选了 PHP 8 + SQLite，而不是更「现代」的组合。理由记录如下。

第一，内存是硬约束。

MySQL 空载就要占两三百 MB，跑起来以后 InnoDB 缓冲池、连接线程还会继续吃内存。2G 机器上再放 Nginx 和系统，留给应用的余量并不多。SQLite 是一个文件，没有常驻进程，内存占用由调用方决定，个人博客这种访问量几乎可以忽略。

第二，PHP-FPM 是按需启动的。

没人访问时 ondemand 模式下进程会退出，不占内存。请求来了再拉起，响应完释放。这跟 Node 常驻进程、JVM 常驻堆的模型完全不同。对个人站来说，这是最诚实的资源利用方式：流量花在请求上，而不是花在「等请求」上。

第三，备份的复杂度差一个数量级。

SQLite 备份一个文件就结束，用 VACUUM INTO 还能拿到一致性快照。MySQL 要考虑 mysqldump、锁、binlog、恢复流程。我不是不想学，而是不想在一个个人博客上维护一套需要预案才能恢复的基础设施。

第四，零依赖意味着零更新面。

整个项目没有 Composer、没有 Node、没有 Docker、没有任何第三方库。PHP 标准库 + PDO 就够了。依赖越少，供应链出问题的面越小，我半年后回来也不需要回忆一堆工具链版本。

当然 SQLite 不是万能的。

它不适合高并发写、不适合多实例部署、不适合大团队。但个人博客 99% 是读，写只有我一个人，在可预见的几年内不会触及它的任何瓶颈。为不会发生的场景付成本，是过早优化。

2G 内存下，水平体现在「知道什么不该装」。

这不是技术上的保守，是运维上的诚实：我要的是一个三年后还能稳定跑、我自己也能完整解释的系统，而不是一份需要持续供养的简历。