rolling() 必须指定 on 参数或 datetime 索引才能按时间滑动，因默认仅支持整数窗口；字符串时间单位（如'7D'）需依赖有序 datetime 索引或 on= 显式指定时间列，否则报 ValueError。
rolling() 为什么必须指定 on 参数才能按时间滑动？
直接对 pd.Series 或未设索引的 DataFrame 调用 rolling('7D') 会报错：ValueError: window must be an integer。因为 pandas 默认把行数当窗口单位，不认字符串时间单位（如 '7D'、'1H'）。只有当数据带有序的 datetime 索引，或显式通过 on= 指定时间列时，pandas 才启用时间窗口逻辑。
实操建议：
- 若时间列叫
'ts'，且是datetime64类型，用df.rolling('7D', on='ts').value.mean() - 若已设时间为索引（
df = df.set_index('ts')），可直接写df['value'].rolling('7D').mean() - 切勿对
object类型的时间列使用 —— 必须先转成pd.to_datetime(df['ts'])
时间窗口对齐：right、left、both 的区别在哪？
默认 rolling('7D', on='ts') 是右对齐（closed='right'），即当前时刻 t 的窗口覆盖 (t−7D, t]。这在实时监控中合理，但容易漏掉首条记录（因无历史数据）；若想包含当前时刻及之前 7 天（含 t），得显式写 closed='both'。
常见错误现象：
- 用默认参数计算日均值，结果比预期少 1 天 —— 实际是窗口不含当天 00:00:00，只含之后的点
-
closed='left'会变成[t−7D, t)，当前时刻永远不算进均值，适合做“预测前平滑” - 高频数据（如秒级）下，
closed='both'可能导致同毫秒内多条记录重复计入，需提前去重或采样
mean() 结果为空或全是 NaN？检查这三点
rolling().mean() 返回 NaN 不一定是数据问题，更可能是窗口没“落稳”。时间窗口不像整数窗口那样每行都有值，尤其在边界和稀疏时间点上。
排查步骤：
- 确认时间列无
NaT：df['ts'].isna().sum()，有则dropna(subset=['ts']) - 检查时间是否单调递增：
df['ts'].is_monotonic_increasing为False会导致滚动中断，需先sort_values('ts') - 窗口太小或数据太稀疏 —— 比如每小时一条数据，却用
'30T'（30 分钟）窗口，结果几乎全 NaN；改用'2H'或加min_periods=1允许降级计算
性能陷阱：resample() 和 rolling() 别混着用
有人想“先按小时聚合再滚动”，于是写 df.resample('1H', on='ts').mean().rolling(24).mean() —— 这实际算的是“每小时均值的移动平均”，不是原始数据的“24 小时内所有点的均值”。二者物理意义不同，尤其当原始数据不均匀时偏差极大。
正确做法取决于目标：
- 要原始粒度的滑动均值 → 直接
df.rolling('24H', on='ts').value.mean() - 要先降频再平滑（如抗噪）→ 明确分两步，并理解信息损失：
df.set_index('ts').resample('1H').first().rolling(24).mean() - 高频数据（>1k/秒）下，
rolling()时间窗口可能慢于整数窗口，可考虑先set_index('ts').sort_index()再计算，避免内部重复排序
时间窗口滚动的核心约束始终是：它依赖真实时间戳的连续性与精度，而不是行序或固定间隔。任何跳过时间校验、强行套用整数窗口思维的操作，都会在边界或异常时间点暴露问题。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
