用 TTL 实现在线用户自动下线，核心是更新 lastHeartbeat 字段（Date 类型）并建单字段 TTL 索引，每次心跳用 updateOne + upsert 保证唯一性，过期延迟约 60 秒，修改 expireAfterSeconds 后需批量更新时间字段才生效。
怎么用 TTL 实现“在线用户”自动下线
MongoDB 本身不支持实时在线状态广播，但用 expireAfterSeconds 配合时间戳字段，能低成本模拟“心跳过期即下线”。核心不是存“在线”，而是存“最后活跃时间”，让 TTL 自动清理陈旧记录。
关键点在于：TTL 不看业务逻辑是否“还连着”，只机械比对 lastHeartbeat 字段值 + expireAfterSeconds 是否早于当前时间。所以必须保证每次心跳都 更新 这个字段，而不是插入新文档。
- 字段类型必须是
Date（不能是字符串或数字时间戳） - 索引只能建在单字段上，例如
{"lastHeartbeat": 1}，不能复合 - 后台删除线程默认每 60 秒扫描一次，所以“下线延迟”最多约 1 分钟
- 如果用户频繁发心跳，建议把
expireAfterSeconds设为实际超时时间的 1.2–1.5 倍，留出网络和写入抖动余量
为什么 updateOne 比 upsert 更稳
常见错误是每次心跳都用 upsert: true 插入新文档——这会导致集合快速膨胀，且 TTL 只作用于插入/更新时带时间字段的文档，旧文档若没被覆盖就永远不参与过期判断。
正确做法是固定用 updateOne 更新已有文档的 lastHeartbeat 字段：
db.onlineUsers.updateOne(
{ userId: "u123" },
{ $set: { lastHeartbeat: new Date() } },
{ upsert: true }
)
这样既确保只有一条记录，又让 TTL 始终基于最新时间重新计算过期窗口。
- 不用
insertOne：否则会残留大量历史记录，TTL 不生效 - 避免在应用层做“先查再更”，直接靠
upsert原子性保障 - 如果用 Node.js 驱动，注意
new Date()必须在 MongoDB 服务端可识别，不要传字符串
expireAfterSeconds 调整后为啥不立刻生效
TTL 索引修改不是热更新：删旧索引、建新索引后，MongoDB 不会回扫已存在文档去重算过期时间。它只对后续写入生效。也就是说，你把过期时间从 300 秒改成 600 秒，已存在的文档仍按老规则走，可能在 5 分钟后就被删了。
- 想让所有文档统一按新策略过期？必须批量重写
lastHeartbeat字段，触发重新评估 - 命令示例：
db.onlineUsers.updateMany({}, { $set: { lastHeartbeat: new Date() } }) - 生产环境慎用该操作，大集合会阻塞写入；建议配合
collMod或分批处理 - 别依赖
dropIndex+createIndex来“重启 TTL”，那只是重建索引结构，不刷新文档状态
为什么上线后总看到“刚连就掉线”
最常踩的坑是字段名或时间值不对：TTL 索引字段缺失、类型错误、或时间设成了过去值，都会导致文档一入库就被标记为“立即过期”。
排查顺序：
- 查文档里有没有
lastHeartbeat字段：db.onlineUsers.findOne({ userId: "u123" }) - 确认字段值是
Date类型，不是字符串：typeof doc.lastHeartbeat === "object"且doc.lastHeartbeat instanceof Date - 检查索引是否存在且参数正确：
db.onlineUsers.getIndexes()，看expireAfterSeconds是否是你设的值 - 留意时区：Node.js 的
new Date()是本地时区，而 MongoDB 存的是 UTC；只要前后一致就没问题，但混用Date.now()（毫秒数）和new Date()就容易错
TTL 的“自动”背后全是静默规则，没有日志、不报错、不提醒——它只在后台默默删，删完也不告诉你。所以验证阶段务必手动插入一个过去时间的文档，等 60 秒后查是否消失，这才是真实反馈。
