快速计算前n个数均值方差：从朴素到增量与数值稳定

1. 从一次数据预处理卡顿说起：为什么“前n个数”的统计值得单独拎出来讲

做数据处理的人多半遇到过这种场景：传感器每隔几毫秒吐一个数，你只想看最近100个采样点的波动情况；或者做滑动窗口特征提取时，每个窗口都要算均值和方差，窗口一多，整个流程就慢得让人想砸键盘。更别提在嵌入式设备或者前端浏览器里跑实时统计，算力本来就紧巴巴的，要是还傻乎乎地每次都把前n个数重新遍历一遍，那真是自己给自己找不痛快。

“快速计算数组中前n个数的均值和方差”这个标题，乍一看像是编程入门课的练习题，但真正把它放到工程环境里，你会发现里面藏着不少门道。均值和方差是最基础的两个统计量，前者描述数据的中心位置，后者刻画数据的离散程度。问题在于，当n很大、或者需要反复对不同的n进行计算时，朴素做法的效率会急剧下降。比如一个长度为100万的数组，你要算前50万个数的方差，直接两遍循环当然能出结果，但如果接下来还要算前50万零1个、前50万零2个……这种增量式的需求，朴素做法就完全不能忍了。

这篇文章面向的是需要在真实项目里处理这类问题的开发者，不管你是做信号处理、金融数据分析、机器学习特征工程，还是单纯在写一个性能敏感的统计工具，这里面的思路和代码都能直接拿去用。我会从最朴素的实现讲起，一步步推到增量更新和数值稳定性的处理，把每个选择背后的“为什么”说清楚，再补上我在实际项目里踩过的坑和总结出来的技巧。全文的代码以Python为主，但思路是跨语言的，你用C++、Java、JavaScript都能照着实现。

先明确一下问题的定义：给定一个数组arr和一个整数n（n不超过数组长度），计算arr[0]到arr[n-1]这n个数的均值和方差。均值的定义是这n个数的总和除以n；方差通常指总体方差，即每个数与均值之差的平方和除以n，如果是要样本方差，则除以n-1。这个区别在实际使用中很关键，后面会专门讲。

2. 朴素解法能跑通，但它的代价你算过吗

2.1 两遍循环的实现与它的时间复杂度

最直观的做法分两步走：第一遍遍历前n个数求和，算出均值；第二遍遍历前n个数，累加每个数与均值之差的平方，再除以n得到方差。用Python写出来大概是这样：

def mean_var_naive(arr, n): total = 0.0 for i in range(n): total += arr[i] mean = total / n sq_sum = 0.0 for i in range(n): diff = arr[i] - mean sq_sum += diff * diff var = sq_sum / n return mean, var

这段代码逻辑没问题，时间复杂度是O(n)，空间复杂度是O(1)。对于单次计算来说，这已经是最优的时间复杂度了，因为你至少得把n个数看一遍。但问题在于“单次”这个前提。如果你的业务只需要算一次，那这段代码完全够用，没必要过度设计。

真正的麻烦出现在需要反复计算的场景。假设你有一个长度为N的数组，需要对n=1,2,3,...,N都算一遍均值和方差，朴素做法的时间复杂度就变成了O(N²)。N等于10万的时候，操作次数就是100亿级别，现代CPU也扛不住。这时候就必须换思路了。

2.2 一遍循环的公式变形：省掉第二次遍历

在讲增量方法之前，先看一个能省掉第二遍循环的技巧。方差有一个等价公式：

Var(X) = E[X²] - (E[X])²

也就是说，方差等于“平方的均值”减去“均值的平方”。这样一来，你只需要遍历一遍数组，同时累加两个量：所有数的和，以及所有数的平方和。遍历结束后，均值等于和除以n，方差等于平方和除以n再减去均值的平方。

def mean_var_one_pass(arr, n): total = 0.0 sq_total = 0.0 for i in range(n): x = arr[i] total += x sq_total += x * x mean = total / n var = sq_total / n - mean * mean return mean, var

这个变形在数学上完全等价，但它引入了一个新的问题：数值稳定性。当数据本身的数值很大，而方差相对很小时，sq_total / n和mean * mean可能是两个非常接近的大数，相减会产生严重的灾难性抵消（catastrophic cancellation），导致算出来的方差精度极差，甚至出现负数。这个问题在后面会详细展开，先记住这个坑。

一遍循环的好处是减少了内存访问次数，对于n很大的情况，性能提升是实打实的。但它并没有解决“反复计算不同n”的效率问题，每次换一个n，还是得从头再来。

2.3 什么时候朴素解法反而是最优选择

说了这么多朴素解法的不是，也得给它说句公道话。在以下几种情况下，直接用朴素解法或者一遍循环的变形就是最好的选择：

• 只算一次：如果整个程序生命周期里只需要计算一次前n个数的统计量，那O(n)就是理论下界，没有任何优化空间。
• n很小：n只有几十或者几百的时候，任何优化带来的收益都被函数调用的开销吃掉了，代码可读性反而更重要。
• 数据只读且不需要增量：如果数据是一次性加载的静态数组，没有后续的增量更新需求，那也没必要维护额外的状态变量。
• 对数值精度要求极高：某些科学计算场景下，两遍循环的精度比一遍循环的公式变形更可靠，因为两遍循环不需要做两个大数相减。

我见过不少项目，开发者一上来就想着上增量、上并行，结果代码复杂度飙升，维护成本翻倍，实际性能提升却微乎其微。优化的第一原则永远是先测量，再优化。拿个profiler跑一下，确认瓶颈真的在这里，再动手也不迟。

3. 增量更新：让每一次“多算一个数”变成常数时间

3.1 均值的增量更新推导

增量更新的核心思想是：利用前n个数的统计量，在O(1)时间内推出前n+1个数的统计量。先看均值，这个比较简单。

设前n个数的和为S_n，均值为M_n = S_n / n。当加入第n+1个数x时，新的和为S_{n+1} = S_n + x，新的均值为：

M_{n+1} = S_{n+1} / (n+1) = (S_n + x) / (n+1)

也可以写成用旧均值表示的形式：

M_{n+1} = (n * M_n + x) / (n+1)

两种写法在数学上等价，但实际编码时推荐用第一种，直接维护和S，避免每次都要乘n再除n+1，减少浮点运算次数。均值的增量更新非常简单，没什么坑。

3.2 方差的增量更新：Welford算法的核心思路

方差的增量更新就没那么直观了。如果直接用E[X²] - (E[X])²的公式，你只需要维护和S以及平方和Q，增量更新就是S += x, Q += x*x，最后算一下就行。但前面说了，这个公式有数值稳定性问题。

更稳健的做法是Welford算法，它直接维护均值和“离差平方和”（sum of squared deviations），每次加入新数据时同时更新这两个量。设前n个数的均值为M_n，离差平方和为C_n（即Σ(x_i - M_n)²），当加入新数x时：

M_{n+1} = M_n + (x - M_n) / (n+1) C_{n+1} = C_n + (x - M_n) * (x - M_{n+1})

最终方差为C_n / n（总体方差）或C_n / (n-1)（样本方差）。

这个算法的精妙之处在于，它每次只处理“新数与旧均值的差”这个量，这个差通常不会太大，避免了两个大数相减的问题。Welford算法在数值稳定性上远优于E[X²] - (E[X])²的公式，是公认的在线方差计算标准方法。

用Python实现一个增量统计类：

class RunningStats: def __init__(self): self.n = 0 self.mean = 0.0 self.M2 = 0.0 # 离差平方和 def update(self, x): self.n += 1 delta = x - self.mean self.mean += delta / self.n delta2 = x - self.mean self.M2 += delta * delta2 def get_mean(self): return self.mean def get_variance(self, ddof=0): if self.n < 2: return 0.0 return self.M2 / (self.n - ddof)

ddof参数控制自由度，ddof=0是总体方差，ddof=1是样本方差。这个类可以一边遍历数组一边更新，遍历到第n个数时，直接读取当前的均值和方差即可，整个过程只需要一次遍历，时间复杂度O(n)，空间复杂度O(1)。

3.3 增量方法的适用边界与精度实测

增量方法虽然好，但也不是万能的。它的主要限制在于：你必须按顺序逐个加入数据。如果你的需求是“随机访问任意前n个数的统计量”，那增量方法就不适用了，因为你没法跳过中间的数据直接算第n个。这种情况下，要么用前缀和加前缀平方和（配合E[X²] - (E[X])²公式，接受精度损失），要么用更复杂的数据结构。

关于精度，我做过一组实测。构造一个数组，前1000个数都是10^8加上一个很小的随机扰动，扰动的标准差大约是1。用三种方法计算方差：

可以看到，当数据均值远大于标准差时，E[X²] - (E[X])²公式会彻底崩溃，而Welford算法依然保持了很好的精度。这个实验说明，如果你的数据可能存在大均值小方差的情况，千万不要用平方和减均值平方的公式。

提示：判断是否属于“大均值小方差”场景，可以粗略看一下数据的量级。如果均值绝对值超过标准差的10倍以上，就应该警惕数值稳定性问题。

4. 数值稳定性：那些让方差算出负数的坑

4.1 灾难性抵消是怎么发生的

灾难性抵消是浮点数运算中的一个经典问题。简单来说，当你用两个非常接近的大浮点数相减时，有效数字会大量丢失。举个十进制例子：假设浮点数只能保留6位有效数字，你要计算1.234567 - 1.234566，真实结果是0.000001，但两个操作数各自被截断后可能变成1.23457和1.23457，相减直接得0，相对误差100%。

在方差计算中，E[X²] - (E[X])²这个公式天然就容易触发灾难性抵消。当数据均值很大时，E[X²]和(E[X])²都是很大的数，而它们的差（方差）可能很小。两个大数相减，有效数字大量丢失，结果自然不可靠。

更隐蔽的是，这个问题不一定在第一次计算时就暴露。有时候数据量小的时候看起来正常，数据量一大、均值一偏移，方差就突然变成负数了。我见过一个线上监控系统，跑了几个月都好好的，某天传感器基线漂移了一下，方差直接报出负值，整个告警逻辑全乱了。

4.2 Welford算法为什么能扛住大均值

Welford算法之所以数值稳定，是因为它从来不构造E[X²]和(E[X])²这两个大数。它维护的是离差平方和C_n，每次更新时计算的是(x - M_n)和(x - M_{n+1})，这两个量都是“数据与均值的偏差”，量级通常远小于数据本身。偏差的乘积再累加，整个过程都在小量级上运算，有效数字保留得更好。

从数学上看，Welford算法的更新公式可以展开验证其正确性，但更重要的是理解它的设计哲学：永远不要让两个大数相减来得到一个小数。这个原则不仅适用于方差计算，在很多数值计算场景里都是通用的。

4.3 补偿求和：Kahan算法在均值计算中的应用

即使是用Welford算法，均值的累加过程本身也可能积累浮点误差。当n很大时，每次加上一个很小的数，可能会因为浮点数的精度限制而“加不进去”。比如一个很大的和加上一个很小的增量，如果两者的量级差距超过浮点数的有效位数，增量就会被直接丢弃。

Kahan补偿求和算法可以缓解这个问题。它的核心思想是维护一个“补偿量”，记录每次加法中丢失的低位部分，在后续加法中补回来：

class KahanSum: def __init__(self): self.sum = 0.0 self.c = 0.0 # 补偿量 def add(self, x): y = x - self.c t = self.sum + y self.c = (t - self.sum) - y self.sum = t

在Welford算法中，均值的更新是mean += delta / n，这个累加过程也可以用Kahan补偿来提升精度。不过实际测试下来，对于大多数工程场景，普通浮点累加的精度已经够用，Kahan带来的提升有限，反而增加了计算量。我的建议是：除非你的数据量特别大（百万级以上）或者对精度要求极其苛刻，否则不必上Kahan。先保证算法层面的数值稳定性（用Welford而不是平方和公式），这比微调累加精度重要得多。

5. 从单次计算到滑动窗口：工程中的变体与取舍

5.1 滑动窗口均值方差的增量更新

实际项目里更常见的是滑动窗口场景：窗口大小固定为n，随着新数据到来，窗口向前滑动，每次去掉最旧的数据、加入最新的数据，然后重新计算窗口内的均值和方差。这种场景下，增量更新不仅要能“加”，还要能“减”。

均值的滑动更新很简单：新均值 = 旧均值 + (新数 - 旧数) / n。方差的滑动更新就复杂一些，需要同时维护和、平方和，或者用Welford的变体。用和与平方和的方式实现滑动窗口：

class SlidingWindowStats: def __init__(self, window_size): self.window_size = window_size self.buffer = [] self.total = 0.0 self.sq_total = 0.0 def update(self, x): if len(self.buffer) == self.window_size: old = self.buffer.pop(0) self.total -= old self.sq_total -= old * old self.buffer.append(x) self.total += x self.sq_total += x * x def get_mean(self): return self.total / len(self.buffer) def get_variance(self): n = len(self.buffer) mean = self.get_mean() return self.sq_total / n - mean * mean

这个实现的问题还是数值稳定性。滑动窗口里，total和sq_total会随着数据的进出不断累加和减少，浮点误差会逐渐积累。如果窗口滑动几百万次，误差可能大到不可忽略。更稳健的做法是用Welford算法的滑动窗口变体，但那个实现复杂度会高不少，需要维护更多中间变量。

我的经验是：如果窗口滑动次数在十万次以内，用和与平方和的简单实现就够了；如果滑动次数上百万，或者数据量级差异很大，就得考虑更稳健的方案。一个折中的办法是每隔一段时间（比如每滑动一万次）用当前窗口内的数据重新计算一次基准值，把累积误差清零。

5.2 并行计算：分块合并统计量

当数据量特别大、单线程处理太慢时，可以考虑并行计算。均值和方差都是可以合并的统计量：如果你有两组数据的均值和方差，可以合并出总体的均值和方差。

设两组数据分别为A和B，大小分别为n_A和n_B，均值分别为M_A和M_B，离差平方和分别为C_A和C_B。合并后的均值为：

M = (n_A * M_A + n_B * M_B) / (n_A + n_B)

合并后的离差平方和为：

C = C_A + C_B + n_A * n_B * (M_A - M_B)² / (n_A + n_B)

这个公式是Welford算法并行化的基础。你可以把数组分成若干块，每块独立计算均值和离差平方和，最后用上面的公式合并。这样就能利用多核CPU或者分布式集群来加速计算。

def merge_stats(n_a, mean_a, m2_a, n_b, mean_b, m2_b): n = n_a + n_b delta = mean_b - mean_a mean = mean_a + delta * n_b / n m2 = m2_a + m2_b + delta * delta * n_a * n_b / n return n, mean, m2

这个合并公式在数值上也是稳定的，因为它同样避免了两个大数相减。实际使用时，把数组切成和CPU核心数相当的块，每块用一个进程或线程计算局部统计量，最后合并即可。Python里可以用multiprocessing或者concurrent.futures来实现，但要注意进程间通信的开销，块的大小要足够大才划算。

5.3 不同场景下的方案选型对照

把前面讲的几种方案整理成一张表，方便你根据实际场景快速选型：

选型的时候不要一味追求最高精度或最快速度，而是要看你的实际约束。嵌入式设备上内存紧张，可能就得用空间复杂度最低的方案；金融风控场景对精度要求极高，那就得上Welford加补偿求和；互联网应用追求吞吐量，分块并行可能更合适。

6. 实测数据与性能对比：这些数字比理论更有说服力

6.1 测试环境与数据集构造

为了给出有参考价值的性能数据，我构造了三组不同规模的数据进行测试。测试环境是一台普通的开发机，Python 3.10，没有用NumPy，纯Python实现，目的是让不同语言背景的读者都能参考。数据集分别是：

• 小规模：n=1000，随机浮点数，范围[0, 100)
• 中规模：n=100000，随机浮点数，范围[0, 100)
• 大规模：n=1000000，随机浮点数，范围[0, 100)
• 大均值小方差：n=100000，基准值10^8，扰动标准差1

测试的方法是每种算法跑100次取平均耗时，同时记录计算出的方差与基准值的相对误差。

6.2 各算法耗时与精度实测结果

从数据可以看出几个有意思的点。首先，一遍循环加平方和公式确实最快，但它在数值稳定性上完全不可靠，大均值小方差场景下直接失效，所以这个速度优势没有实际意义。其次，Welford增量比两遍循环慢了大约20%，这个代价换来的是数值稳定性和增量更新的能力，我认为是值得的。最后，分块并行在数据量大时优势明显，n=100万时耗时只有单线程的三分之一左右，接近4核的理想加速比。

6.3 内存占用与GC影响的观察

除了耗时，内存占用也是选型时要考虑的。两遍循环和Welford增量的空间复杂度都是O(1)，只用了几个标量变量，内存占用可以忽略。分块并行需要把数据切分并传递给各个进程，内存占用会成倍增加，如果数据本身很大，可能反而成为瓶颈。

另外在Python环境下，频繁创建和销毁对象会触发垃圾回收，影响性能。Welford增量实现中如果每次update都创建新对象，GC压力会比较大。我的做法是把RunningStats设计成可变对象，update方法直接修改内部状态，不创建新对象。实测下来，这个改动能让n=100万时的耗时降低约15%。

注意：在Python里做数值计算，如果数据量真的很大，优先考虑NumPy。NumPy的底层是C实现的，向量化操作比纯Python循环快几十倍。但NumPy的var函数默认用的是两遍循环算法，数值稳定性有保障，只是不支持增量更新。如果需要增量，还是得自己实现。

7. 我踩过的坑和几条实用建议

7.1 方差为负数不是灵异事件

第一次遇到方差算出负数的时候，我以为是数据有问题，排查了半天才发现是公式的数值稳定性问题。后来查资料才知道，这是浮点计算里的经典坑。如果你也遇到了方差为负的情况，不要怀疑人生，先检查是不是用了E[X²] - (E[X])²的公式，然后换成Welford算法，大概率就解决了。

还有一种情况是数据本身有问题，比如混入了NaN或者Inf。NaN会污染整个计算过程，任何数与NaN运算结果都是NaN。Inf则会导致均值变成Inf，方差变成NaN。所以在计算之前，最好先检查一下数据里有没有异常值。一个简单的做法是加一个断言：

import math assert all(math.isfinite(x) for x in arr[:n]), "数据中包含非有限值"

这个检查会带来额外的O(n)开销，如果数据来源可靠，可以只在调试阶段开启。

7.2 样本方差还是总体方差，别用错了

总体方差除以n，样本方差除以n-1。这个区别在统计学教科书里讲得很清楚，但实际编码时很容易搞混。简单来说，如果你手上的数据就是全部总体，用n；如果数据只是总体的一个样本，你想估计总体方差，用n-1。在机器学习特征工程里，通常用总体方差，因为你就是把当前这批数据当作全部来处理。在A/B测试的统计分析里，通常用样本方差，因为你要推断的是更大总体的性质。

用错了会怎样？n很大的时候差别不大，n很小的时候差别就明显了。n=2的时候，样本方差是总体方差的两倍。所以如果你的窗口很小，一定要确认清楚用哪个。

7.3 窗口大小变化时的重新计算策略

滑动窗口场景下，有时候窗口大小会动态变化。比如系统负载高的时候用大窗口平滑数据，负载低的时候用小窗口提高响应速度。窗口大小变化时，之前维护的统计量就不能直接用了，因为均值和方差都依赖于窗口大小。

我的做法是维护一个固定大小的环形缓冲区，窗口大小变化时，用缓冲区里的数据重新计算一次统计量。重新计算的成本是O(n)，但只要窗口大小不是频繁变化，这个开销可以接受。如果窗口大小变化很频繁，那就得考虑更复杂的数据结构，比如用两个堆或者平衡树来维护，但实现复杂度会高很多，一般项目里没必要。

7.4 整数数组的溢出问题

如果数组里存的是整数，而且数值比较大，累加和平方的时候要注意溢出。比如32位整数，最大值约21亿，如果数组里有1000个100万的数，和就超过21亿了，直接溢出。Python的整数是任意精度的，不会有这个问题，但C++、Java、JavaScript里就要小心。JavaScript的Number是双精度浮点数，安全整数范围是2^53-1，超过这个范围精度就会丢失。

解决办法很简单：累加的时候用浮点数或者更大范围的整数类型。C++里用long long或者double，Java里用long或者double。但要注意，用浮点数累加整数会引入浮点误差，如果对精度要求高，还是用大整数类型更稳妥。

7.5 什么时候该用现成的库

最后说一个务实的建议：如果你的需求不是特别定制化，优先用现成的库。Python里NumPy的mean和var函数已经处理好了数值稳定性问题，性能也足够好。如果是在线增量计算，statsmodels或者river这些库里有现成的实现。自己实现的好处是可控、可定制，但代价是要自己处理各种边界情况和数值问题。

我的判断标准是：如果标准库或成熟第三方库能覆盖你的需求，而且性能满足要求，那就直接用，把精力省下来做业务逻辑。只有当你有特殊需求（比如极致的性能、特殊的数据结构、嵌入式环境）时，才值得自己造轮子。造轮子之前，也建议先看看有没有开源的实现可以参考，站在别人的肩膀上总比自己从零开始强。

方差计算这件事，看起来简单，但真要做好，里面的细节比想象中多。从朴素两遍循环到Welford增量，再到并行合并，每一步的演进都是为了解决特定场景下的特定问题。理解这些方案背后的取舍逻辑，比记住某一段代码更重要。毕竟代码会过时，但解决问题的思路不会。