expireAfterSeconds不生效的主因是时间字段非Date类型或索引配置错误：必须使用Date对象（非字符串/时间戳）、单字段升序索引、字段须为索引首列，且后台清理每60秒执行一次。
为什么 expireAfterSeconds 不生效？常见配置陷阱
最常遇到的问题是索引建了，但文档没删——根本原因是 expireAfterSeconds 只作用于 **已存在时间字段的索引**，且该字段必须是 Date 类型。如果字段是字符串（如 "2024-01-01T00:00:00Z"）或数字时间戳，TTL 索引完全不识别。
实操建议：
- 确认字段值是真正的
Date对象：插入时用new Date()或ISODate()，别用字符串 - 索引必须建在该时间字段上，不能是复合索引的第二列（除非第一列是该时间字段）
- 后台 TTL 删除任务每 60 秒扫描一次，不是实时删除，别拿
find()验证“立刻消失”
如何正确创建 TTL 索引：命令与字段位置关键点
TTL 索引本质是带 expireAfterSeconds 选项的单字段升序索引。字段名可以任意（比如 createdAt、updatedAt、expireAt），但必须是 Date 类型。
示例（Mongo Shell）：
db.sessions.createIndex(
{ "createdAt": 1 },
{ expireAfterSeconds: 3600 }
)注意：
-
createdAt字段必须已存在且类型为Date，否则索引创建成功但无效 - 不能写成
{ "createdAt": -1 }（降序），TTL 要求升序 - 若想按更新时间过期，字段名换成
updatedAt，但每次更新需手动重置该字段值
多个 TTL 索引能共存吗？和普通索引冲突吗？
可以共存，MongoDB 允许一个集合有多个 TTL 索引，只要它们作用于不同字段。但一个字段上只能有一个 TTL 索引（后建的会覆盖前一个）。
和普通索引无冲突，TTL 索引本身也是普通 B-tree 索引，只是多了后台清理逻辑。不过要注意：
- 每个 TTL 索引都会增加后台扫描开销，生产环境不建议堆砌多个
- 如果两个 TTL 索引指向同一字段（比如都建在
createdAt上），第二个会替换第一个，不会报错 - 复合索引加
expireAfterSeconds仅当时间字段是第一列才有效，例如{ "createdAt": 1, "userId": 1 }可以，但{ "userId": 1, "createdAt": 1 }不行
测试 TTL 是否工作：绕过“60秒延迟”的验证方法
等 60 秒太慢，可以用 db.runCommand({ "setParameter": 1, "ttlMonitorEnabled": false }) 关闭监控，再手动触发清理（仅开发/测试环境）：
db.runCommand({ "setParameter": 1, "ttlMonitorEnabled": false })
db.sessions.deleteMany({ "createdAt": { $lt: new Date(Date.now() - 3600 * 1000) } })或者更直接：把 expireAfterSeconds 设成 1，插入一条 2 秒前的数据，等 60 秒后查是否消失。
容易被忽略的是：TTL 删除只检查索引字段值，不关心文档其他字段是否存在或是否满足业务条件——它纯粹是“时间到了就删”，没有事务回滚、没有钩子、不可中断。
