Mongoose如何在TTL删除文档事件触发后执行自定义清理函数

首先明确一个核心前提：MongoDB TTL索引触发的自动删除是内核层面的后台批量异步操作，不会经过Mongoose的文档操作链路，因此你写在Schema上的pre('remove')/post('deleteOne')这类Mongoose中间件钩子完全不会被触发，没法直接靠钩子捕获TTL删除事件执行自定义逻辑。

目前生产环境落地这类需求有两类成熟方案，优先推荐第一种，稳定性最高、实现成本最低：

方案1：自主可控的定时任务清理（推荐） #

不要完全依赖TTL机制执行业务关联清理，把TTL作为兜底数据清理手段，核心的过期判断、资源删除、数据删除逻辑全部由自定义定时任务实现：

• 保留现有softDeleted、expireAt字段设计，原TTL索引可以保留，但把过期时间留冗余（比如设置expireAfterSeconds为17天对应的秒数，比业务要求的15天多2天），作为定时任务异常时的兜底防堆积策略。
• 引入定时调度能力（用node-schedule、cron这类包即可，对实时性要求不高的场景甚至可以每天凌晨低峰期跑一次，毕竟15天的保留窗口允许几小时的误差），定时执行以下逻辑：
  • 查询所有满足softDeleted = true且expireAt <= 当前时间的过期场地文档
  • 遍历文档，先提取所有关联存储资源：images数组、coverImageURL、videos字段的路径，调用存储服务的删除接口清理所有文件
  • 确认文件删除成功后，再调用Mongoose的deleteOne永久删除对应数据库文档

示例实现代码：

const schedule = require('node-schedule');

// 定时任务规则：每小时整点执行一次过期清理，可根据业务对实时性的要求调整频率
schedule.scheduleJob('0 * * * *', async () => {
  try {
    // 批量查询所有已过期的软删除场地
    const expiredVenues = await Venue.find({
      softDeleted: true,
      expireAt: { $lte: new Date() }
    });

    for (const venue of expiredVenues) {
      // 收集所有需要删除的关联文件路径，过滤空值
      const allRelatedFiles = [
        ...venue.images,
        venue.coverImageURL,
        venue.videos
      ].filter(Boolean);
      
      // 替换成你实际使用的存储删除逻辑：本地存储用fs.unlink，云存储调用对应SDK的删除方法
      await Promise.all(allRelatedFiles.map(filePath => deleteFileFromStorage(filePath)));
      
      // 资源清理完成后再删除数据库记录
      await Venue.deleteOne({ _id: venue._id });
    }
  } catch (err) {
    console.error('过期场地清理任务执行异常：', err);
    // 这里可加告警逻辑，及时发现任务失败避免数据/垃圾文件堆积
  }
});

额外提醒：你当前的软删除接口代码存在字段名笔误：Schema中定义的软删除标记字段是softDeleted，但接口里写的是venue.softDelete = true，会导致软删除标记不生效、TTL倒计时无法正常启动，记得修正。

方案2：MongoDB变更流捕获删除事件（不推荐） #

如果你的MongoDB是副本集或分片集群架构（单节点实例不支持该特性），可以通过Change Streams监听集合的删除事件，触发关联资源清理：

• 需要提前在集合上开启changeStreamPreAndPostImages配置，才能在删除事件中拿到被删文档的原始字段（否则只能拿到被删文档的_id，拿不到images等资源路径字段）
• 监听Venue集合的delete类型事件，拿到被删文档的资源路径后执行文件删除
• 该方案的缺陷很明显：架构要求高、需要额外处理事件消费中断/重复消费/丢消息的问题，运维成本高，远不如定时任务方案简单可靠，因此非特殊场景不建议使用。

内容的提问来源于stack exchange，提问作者m_dot_dev