groupby().rolling()报valueerror因分组后索引非datetime64类型且未排序；需显式设时间列为索引或用on参数指定，并确保每组内时间单调。
为什么 groupby().rolling() 会报 ValueError: window must be an integer
直接对分组后对象调用 rolling() 时，如果窗口参数传了字符串（比如 '7D'）但分组键含非时间列，Pandas 无法自动对齐时间索引，就会抛这个错。根本原因是：分组后的子 DataFrame 默认没有时间索引，rolling('7D') 要求索引是 datetime64 类型且已排序。
实操建议：
- 先确保原始数据有合法的
datetime列，并用set_index()或sort_values()+rolling(..., on=...)显式指定时间基准 - 若按多个字段分组（如
['user_id', 'category']），必须保证每个分组内时间列单调——否则rolling(on='ts')会静默跳过乱序部分，结果不完整 - 避免在
groupby()后链式调用rolling('7D').mean()；优先改用groupby(...).apply(lambda g: g.sort_values('ts').rolling('7D', on='ts').value.mean())
如何让滚动窗口跨分组边界失效、严格限制在每组内部
默认情况下，groupby().rolling() 是“组内独立计算”的，但容易被误以为会自动处理边界——其实不会。例如某组只有 2 条记录，你设 window=5，结果前 4 行全是 NaN，这不是 bug，是设计行为。
实操建议：
- 用
min_periods=1让窗口从第一个值就开始计算（如累计均值），而不是等满窗才出值 - 若需“最近 N 条非空记录”而非“最近 N 秒”，必须先用
groupby().apply()配合tail(N)手动截取，再聚合，不能依赖rolling(window=N) - 注意
rolling(window=N).sum()和rolling(window=N).apply(lambda x: x.dropna().sum())行为不同：前者遇NaN直接传播，后者可定制缺失值逻辑
多条件分组 + 时间窗口 + 动态权重怎么组合
比如要按 ['region', 'product_type'] 分组，在每组内按 order_date 做 30 天滚动加权平均，权重随天数指数衰减——rolling() 原生不支持自定义权重函数。
实操建议：
- 放弃
rolling().apply()做逐窗口加权（性能极差），改用groupby().apply()+scipy.signal.convolve或手动循环（小数据量可接受） - 更稳的路子：先用
sort_values(['region','product_type','order_date'])，再用groupby(['region','product_type'], group_keys=False)+apply内部做rolling('30D', on='order_date').apply(lambda w: np.average(w, weights=np.exp(-np.arange(len(w))[::-1]/10))) - 权重数组长度必须和当前窗口实际长度一致，
np.arange(len(w))比硬写range(30)安全，否则越界报错
性能卡在 groupby().apply() 上怎么办
当分组数超 10k、每组平均记录超 100 条时，groupby().apply() 会明显变慢，因为 Python 层循环无法向量化。
实操建议：
- 优先尝试
rolling(..., closed='both')+groupby(..., observed=True)减少类别开销 - 把时间列转成
pd.IntervalIndex预切片，用merge_asof()模拟滚动窗口（适合左闭右开场景） - 真到瓶颈，就导出关键列（分组键、时间、数值）到 NumPy 数组，用
numba.jit写裸循环——别省这一步，Pandas 的 rolling 在复杂条件下面向编译器优化很弱
多条件分组滚动最易忽略的点：分组键顺序影响 groupby 的 hash 效率，['user_id', 'date'] 比 ['date', 'user_id'] 更快，尤其当 user_id 是整数且离散度高时。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
