用np.convolve()做滑动平均时，权重必须预先归一化（如np.ones(3)/3），并优先选用mode='valid'以避免边界干扰；mode='same'默认补零易引入偏差，而手动切片均值法效率低、边界难处理。
用 np.convolve() 做滑动平均，权重必须归一化
直接拿 np.convolve() 算滑动平均，结果常比原始数据大几倍——因为默认没做归一化。卷积核（比如 [1, 1, 1]）只是求和，不是求均值。
- 正确做法是把卷积核除以长度：
np.convolve(data, np.ones(3)/3, mode='valid') -
mode='valid'最安全：只保留完全重叠的输出，不引入边界填充噪声 - 如果要用
mode='same'对齐原数组长度，np.convolve()不会自动补零或镜像，得自己处理边界，容易偏移 - 注意：归一化必须在传入前完成，不能靠后续除长度——浮点误差和截断会让结果不准
为什么不用 np.mean() 配合切片？
手动循环切片 + np.mean() 看似直观，但实际慢、易错、难对齐。
- 纯 Python 循环触发解释器开销，10 万点数据可能慢 5–10 倍
- 边界处理麻烦：比如窗口大小为 5，第 0 个点该取哪几个索引？
data[0:5]还是补零？np.convolve()的mode参数直接定义了行为 - 向量化缺失：每次调用
np.mean()都要新建子数组，内存不连续，CPU 缓存不友好 - 真要调试逻辑，建议先用小数组手算验证卷积核和
mode组合是否符合预期
np.convolve() 的 mode 怎么选
三种模式影响输出长度和数值合理性，不是“哪个方便选哪个”。
-
mode='full'：输出长度 = len(data) + len(kernel) - 1，开头结尾全是卷积核“拖尾”，基本不用 -
mode='valid'：输出长度 = len(data) - len(kernel) + 1，严格要求完整重叠，最常用，无假设、无填充 -
mode='same'：输出长度 = len(data)，但内部按补零实现——若原始数据首尾有突变，补零会引入虚假衰减，慎用 - 没有“自动智能补全”：想用镜像或周期延拓，得先用
np.pad()预处理，再调np.convolve(..., mode='valid')
性能与精度的隐性代价
np.convolve() 快，但不是零成本；尤其在嵌入式或实时场景下，几个细节会咬人。
- 输入必须是
float64或float32：如果传int64数组，内部会升到float64计算，内存翻倍、缓存更差 - 卷积核太长（比如 > 1000 点）时，
np.convolve()仍用直接卷积，复杂度 O(n·k)，此时应换 FFT 方法（scipy.signal.fftconvolve） - 小窗口（如 3–5 点）下，
np.convolve()比纯 NumPy 的sliding_window_view+mean略快，但后者语义更清晰、边界可控 - 别为了“一行写完”硬套
np.convolve()：如果后续还要做导数、检测极值，保持原始采样对齐比省两行代码重要得多
滑动平均看着简单，但窗口怎么对齐、边界怎么算、类型怎么转，每步都卡在实际数据上。别信“默认参数刚好够用”——跑通不等于算对。
