本文介绍如何使用mgo.v2为MongoDB集合创建TTL索引，使仅含有效expireAt字段的文档被自动删除，而缺失该字段的文档永久保留，从而在同一集合中灵活支持持久化与临时数据共存。
本文介绍如何使用mgo.v2为mongodb集合创建ttl索引，使仅含有效`expireat`字段的文档被自动删除，而缺失该字段的文档永久保留，从而在同一集合中灵活支持持久化与临时数据共存。
在Go应用中集成MongoDB的TTL（Time-To-Live）机制，关键在于正确建模数据结构、精确配置索引，并理解MongoDB对空值与零值的处理逻辑。mgo.v2虽未直接暴露expireAfterSeconds: 0的原始语法，但可通过ExpireAfter: 0配合omitempty标签实现完全等效的行为——即：仅当文档实际包含一个有效的expireAt时间戳时，才触发自动过期。
✅ 正确配置TTL索引
TTL索引必须基于一个Date类型字段（如expireAt），且ExpireAfter设为0，表示MongoDB应立即检查该字段值并以其绝对时间为准执行删除：
index := mgo.Index{
Key: []string{"expireAt"},
ExpireAfter: 0, // 关键：0 表示使用 expireAt 字段的绝对时间，而非相对偏移
Background: true,
Sparse: true, // 强烈建议启用 sparse！见下文说明
}
err := collection.EnsureIndex(index)
if err != nil {
log.Fatal("Failed to create TTL index:", err)
}
⚠️ 注意：Sparse: true 是本方案的核心保障。它确保索引仅包含存在expireAt字段且其值为有效日期的文档。若省略此选项，time.Time{}零值（即0001-01-01T00:00:00Z）会被MongoDB视为合法日期，导致所有未显式设置expireAt的文档在创建瞬间即满足“已过期”条件，从而被后台任务误删——这与设计目标完全相悖。
✅ 数据结构设计：用omitempty控制字段存在性
结构体需明确声明expireAt字段为可选，避免零值被意外写入数据库：
type Filter struct {
Timestamp time.Time `bson:"createdAt"`
Body string `bson:"body"`
ExpireAt time.Time `bson:"expireAt,omitempty"` // ← 关键：零值不序列化到BSON
}
如此，当用户操作为"share"（需临时存储）时，显式赋值：
filter.ExpireAt = time.Now().Add(14 * 24 * time.Hour) // 14天后过期
该字段将写入数据库，且因索引为sparse，此文档被纳入TTL管理。
而当操作无需过期（如"save"）时，filter.ExpireAt保持零值，omitempty阻止其写入，文档在集合中完全“隐身”于TTL索引之外，实现永久保留。
✅ 完整工作流示例
// 1. 创建带 sparse TTL 索引（一次执行即可）
_ = collection.EnsureIndex(mgo.Index{
Key: []string{"expireAt"},
ExpireAfter: 0,
Background: true,
Sparse: true,
})
// 2. 插入永久文档（无 expireAt 字段）
permanent := Filter{
Timestamp: time.Now(),
Body: "This stays forever",
// ExpireAt 未赋值 → omitempty 生效 → BSON 中无此字段
}
collection.Insert(permanent)
// 3. 插入临时文档（含有效 expireAt）
temp := Filter{
Timestamp: time.Now(),
Body: "Auto-deleted after 1h",
ExpireAt: time.Now().Add(time.Hour),
}
collection.Insert(temp)
// 4. 后续可动态转为临时（例如用户点击“设为过期”）
query := bson.M{"_id": tempID}
update := bson.M{"$set": bson.M{"expireAt": time.Now().Add(24 * time.Hour)}}
collection.Update(query, update)
⚠️ 重要注意事项
- 零值陷阱：time.Time{}在Go中是合法值，但MongoDB将其解析为公元元年。务必结合sparse: true和omitempty双重防护，杜绝零值入库。
- 索引唯一性：TTL索引不可设为Unique，否则会与sparse冲突。
- 后台任务延迟：MongoDB每60秒扫描一次TTL索引，过期文档的实际删除存在分钟级延迟，不适用于毫秒级精度场景。
- 替代方案权衡：若业务要求强实时清理，建议改用定时Job + Remove()查询，或在应用层结合Redis缓存做双校验。
通过以上配置，你便能在单个MongoDB集合中优雅地混合持久化与自动清理数据，兼顾灵活性与运维简洁性。
