滚动平均最直接用numpy.convolve(x, np.ones(w)/w, mode='valid')；注意边界处理，含NaN时优先用pandas.Series.rolling(w).mean()，禁用Python循环。
用 numpy.convolve 做滚动平均最直接
滚动平均本质是窗口内求均值，而卷积操作天然适合这种滑动加权求和。对等权窗口，numpy.convolve 配合归一化系数就能一步到位。
常见错误是忽略边界处理方式：mode='valid' 会丢弃首尾无法完整覆盖的元素，mode='same' 则保持长度但首尾用零填充（结果偏小）；实际中多数情况应选 'valid'，再手动补前缀或插值。
- 窗口大小为
w时，权重数组用np.ones(w) / w - 输入数组为
x，计算：np.convolve(x, np.ones(w)/w, mode='valid') - 若需与原数组等长且首尾合理，建议用
scipy.ndimage.uniform_filter1d(x, size=w, mode='nearest')替代
用 numpy.lib.stride_tricks.sliding_window_view 更灵活但内存敏感
这是 NumPy 1.20+ 引入的官方滑动窗口工具，返回一个视图而非拷贝，支持任意维度、任意函数映射，适合需要自定义窗口逻辑（比如剔除 NaN 后再均值）的场景。
容易踩的坑是误以为它不占额外内存——虽然底层是视图，但后续调用 .mean(axis=-1) 会触发完整副本生成，对大数组可能爆内存。
立即学习“Python免费学习笔记（深入）”；
- 基本用法：
from numpy.lib.stride_tricks import sliding_window_view；windows = sliding_window_view(x, window_shape=w)；rolling_mean = windows.mean(axis=-1) - 注意
windows的 shape 是(len(x)-w+1, w)，不是原始长度 - 若
x是 float32，windows.mean()默认按 float64 算，可加dtype=x.dtype控制精度和内存
pandas.Series.rolling().mean() 为什么有时比纯 NumPy 快？
很多人默认“NumPy 肯定比 pandas 快”，但在滚动平均这类带状态的序列操作上，pandas 底层用了 Cython 优化的累积逻辑，尤其在中等窗口（几十到几百）和含缺失值场景下，实际耗时常低于手写 NumPy 循环或 convolve。
关键点在于：pandas 默认跳过 NaN，而 np.convolve 和 sliding_window_view 都会把 NaN 当数值参与运算，导致结果全为 NaN——这点极易被忽略。
- 安全做法：先用
pd.Series(x).rolling(w).mean().to_numpy() - 若原始数据是纯数字无 NaN，且追求极致速度，仍优先用
convolve - 注意
rolling(...).mean()默认min_periods=1，前w-1个位置会返回部分窗口均值；如需严格只输出完整窗口结果，加参数min_periods=w
避免用 Python 循环实现滚动平均
哪怕只是写个 for i in range(len(x)-w+1): result[i] = x[i:i+w].mean()，在数组长度超 10⁴ 时就会明显慢于向量化方法，且随着 w 增大，时间复杂度从 O(n) 退化为 O(n·w)。
更隐蔽的问题是：每次切片 x[i:i+w] 都新建临时数组，频繁内存分配拖慢整体速度，且 GC 压力增大。
- 绝对不要在性能敏感路径里用这种循环
- 调试或极小数据（
len(x) ）时可用，但别当成惯性写法 - 如果非得用循环（比如窗口逻辑极其复杂），至少用 Numba 的
@njit编译，否则不如换方法
真正影响选择的不是“哪个函数看起来高级”，而是你的数据有没有 NaN、是否必须等长输出、内存是否受限、以及 NumPy 版本是否 ≥ 1.20。很多项目卡在“想当然用 convolve 却没处理 NaN”，最后发现 pandas 反而更稳。
