这个博客的 Node 版本用了一个 JSON 文件存所有文章。有人觉得这是玩具，但对手里只有几十篇文章的站点来说，它是划算的。

为什么够用

数据量小的时候，全量读进内存再过滤，比任何索引都快——省掉了一次磁盘寻址和查询规划。

JS
let DB = JSON.parse(fs.readFileSync('blog_data.json', 'utf8'));
const page = DB.articles
  .filter(a => a.category === cat)
  .sort((x, y) => new Date(y.created_at) - new Date(x.created_at))
  .slice(offset, offset + perPage);

什么时候会崩

  1. 并发写：writeFileSync 不是原子的，两个请求同时保存会互相覆盖，甚至留下半截文件
  2. 数据量：几千条之后，每次请求解析整个文件就开始能感知到慢了
  3. 查询：多条件筛选、聚合、关联，写到第三层就会开始怀念 SQL

低成本加固

先写临时文件再改名，rename 在同一文件系统里是原子的，读到的永远是完整版本：

JS
function saveData(data) {
  const tmp = FILE + '.tmp';
  fs.writeFileSync(tmp, JSON.stringify(data, null, 2));
  fs.renameSync(tmp, FILE);
}

再配一个进程内互斥锁，写操作串行化。做到这两点，JSON 文件能撑到日均几千 PV。

我的分界线

  • 单写者（只有自己在后台发文）→ JSON 文件
  • 多用户、要事务、要按条件查 → 直接上 SQLite
SQLite 也是单文件，零配置，cp blog.db blog.db.bak 就是备份。它比 JSON 方案多的只是解析和查询那一层，部署难度完全一样。个人项目其实可以直接从 SQLite 起步。