Nuxt 3 个人站内容状态机：用 MongoDB 管理草稿、定时发布与下线

给个人站写文章久了，会发现「是否发布」一个布尔值不够用：想提前存草稿、想定时上线、也想让活动页到期自动下线。我后来把文章当成一个简单状态机，用 MongoDB 存状态和时间，再用 Node.js 定时任务推进状态，成本不高，但足够稳。

状态字段：把发布流程写进数据里

• status：draft、scheduled、published、offline，分别表示草稿、定时待发布、已发布、已下线。
• publishAt：计划发布时间；只有到达该时间才允许前台展示。
• offlineAt：可选下线时间；到期后不再展示。
• updatedAt / publishedAt：记录修改和真实发布时间，方便排查。

这里的关键是不要让前台接口临时判断一堆布尔值，而是把流程沉淀成字段。后台编辑时只改 status 和相关时间，前台查询只相信状态机。这样即使以后接入 Redis 缓存，也能按状态和更新时间做失效。

查询与索引：只查该展示的内容

前台列表通常只需要查已发布、已到发布时间、且未下线的文章。时间建议统一存 UTC，避免本地时区造成定时发布错乱。给常用查询建复合索引，能明显减少扫描量。

await db.collection('articles').createIndex({
  status: 1,
  publishAt: 1,
  offlineAt: 1
});

const now = new Date();
const list = await db.collection('articles').find({
  status: 'published',
  publishAt: { $lte: now },
  $or: [{ offlineAt: null }, { offlineAt: { $gt: now } }]
}).sort({ publishAt: -1 }).limit(20).toArray();

Node.js 定时任务：推进状态迁移

定时任务不需要很复杂：每分钟检查一次到期文章，把 scheduled 且 publishAt 已到的改成 published，把 published 且 offlineAt 已到的改成 offline。更新时最好带上原状态条件，避免重复执行或误更新。

1. 扫描 scheduled 且 publishAt <= now 的文章。
2. 扫描 published 且 offlineAt <= now 的文章。
3. 使用条件 updateMany 更新状态，保证幂等。
4. 更新成功后清理对应页面或接口缓存，例如 Redis 里的列表缓存。

“小站内容管理不一定要上重型 CMS。状态清楚、索引到位、任务可观测，很多需求就自然长出来了。”