弹幕时间戳应存为毫秒级或秒级number（如124.8），而非date；因弹幕是相对偏移量，用date会导致时区混乱、精度冗余、索引低效；推荐建复合索引{videoid:1,time:1}，并辅以dateday字段支持按日聚合。
弹幕时间戳该存成 Number 还是 Date？
直接存成毫秒级 Number（如 124800 表示 2:04.8 秒）更合理。弹幕本质是相对于视频起始的偏移量，不是绝对时间，Date 类型会引入时区、精度冗余和索引膨胀问题。
常见错误是用 new Date(timestamp) 存绝对时间，结果查“第 3 分钟的弹幕”要写 { time: { $gte: new Date('...'), $lt: new Date('...') } }，既难读又慢——MongoDB 对 Date 范围查询无法高效利用前缀索引。
- 统一用
Number存毫秒或秒（推荐秒，小数点后保留 1 位，如124.8） - 建复合索引时把
time放前面：{ videoId: 1, time: 1 } - 如果业务需要“某天所有视频的弹幕热力图”，再额外加一个
dateDay字段（格式"2024-06-15"），不混用Date
aggregate() 做时间片聚合：$bucket 和 $bin 怎么选？
MongoDB 7.0+ 推荐用 $bin，它比 $bucket 更轻量、支持动态步长、且输出结构更干净；5.x/6.x 只能用 $bucket。
典型场景：统计每 5 秒内弹幕数量，生成热力时间轴。
-
$bin示例（7.0+）：{ $bin: { field: "time", bins: { interval: 5 } } }输出字段自动叫_id，值为0、5、10… -
$bucket示例（兼容旧版）：{ $bucket: { groupBy: "$time", boundaries: [0,5,10,15], default: "other" } }必须预设boundaries，视频长了得手动扩数组 - 别在
$bucket里用output: { count: { $sum: 1 } }后再$sort——先$group再$sort更稳，避免边界错位
高并发写入弹幕时，time 字段重复导致聚合不准怎么办？
用户同一毫秒发多条弹幕很常见，time 值相同会导致 $bin 或 $bucket 把它们压进同一个桶，但实际播放时这些弹幕是逐条刷出的——聚合结果会低估瞬时密度。
这不是模型缺陷，而是原始数据粒度不足。解决思路不是强行去重，而是补维度：
- 加一个
seq字段（整型递增），同一time下按顺序编号，如{ time: 124.8, seq: 1 }、{ time: 124.8, seq: 2 } - 聚合时用
{ $bin: { field: { $add: ["$time", { $divide: ["$seq", 100] }] }, bins: { interval: 5 } } }，把序号折算成微小偏移，让同秒弹幕轻微散开 - 注意：这个偏移仅用于聚合分桶，不改变原始
time值，前端播放仍按原值渲染
从「每秒弹幕数」到「密集时间点」：怎么标出真正值得关注的峰值？
单纯看每秒计数会漏掉短时爆发（比如 0.3 秒内 12 条），也容易被噪声干扰（某秒突然多 2 条）。需要滑动窗口平滑 + 阈值过滤。
做法是在应用层做二次处理，而不是全靠 MongoDB 一步到位：
- 先用
$bin聚出每 0.5 秒的计数（粒度够细），输出到临时集合 - 再用
$setWindowFields算 3 秒滑动窗口总和：{ $setWindowFields: { sortBy: { _id: 1 }, output: { winSum: { $sum: "$count", window: { documents: [-6, 0] } } } } }（因 0.5 秒一桶，3 秒 = 6 桶） - 最后
$match: { winSum: { $gt: 20 } }找出密集区间，取_id（即起始时间点）作为标记
这个逻辑没法塞进单个聚合管道里跑完，必须拆步——很多人卡在这儿，硬写超长 pipeline 反而查不出结果。
