如何通过数组前缀和技术实战解决连续子数组变量求和性能优化难点

先抛出一个核心结论：当问题变成“找出数组中和为k的连续子数组个数”时，暴力解法是O(n²)级的——而用前缀和配合哈希表，能直接压到O(n)。这条优化路径不只在题解里好看，放到真实业务场景（比如日志分析、实时风控）里也扛得住百万级数据。所用的数学逻辑很简单：用preSum[i]表示数组前i个元素之和，那么任意子数组的和preSum[i+1] - preSum[j]就等价于一次减法——再通过哈希表统计preSum[j]的频次，实现O(1)查询。

来看具体实现。

直接上结论：前缀和的好处在于，它把反复遍历求和的O(n)操作，变成了单次减法——常数时间。加上哈希表辅助，整个问题的复杂度从暴力双循环的O(n²)直接降为O(n)。这不是理论优化，是工程里真正能用的东西。

前缀和：从反复求和到查表相减

preSum的定义很简单：preSum[i]表示原数组nums中前i个元素的和（索引0到i-1），并设preSum[0]=0。这样一来，子数组nums[j..i-1]的和就等于preSum[i] - preSum[j]。

举个例子，nums = [1, 2, 3, −3, 3]，对应的前缀和为：
preSum = [0, 1, 3, 6, 3, 6]

要算nums[0..1]（即[1,2]）的和？→ preSum[2] - preSum[0] = 3 - 0 = 3
要算nums[2..4]（即[3,−3,3]）？→ preSum[5] - preSum[2] = 6 - 3 = 3

关键动作就两个：
• 构建preSum只需一次O(n)遍历；
• 后续任意区间求和都变成常数时间的减法，不再需要循环叠加。

哈希表补上最后一块拼图

现在目标是统计所有满足sum(nums[j..i]) == k的子数组。用前缀和改写条件：preSum[i+1] - preSum[j] == k → preSum[j] == preSum[i+1] - k。

翻译乘人话：当遍历到位置i+1时，只需要知道之前有多少个j（j ≤ i），使得preSum[j]等于当前值减去k——这数字也就是新增的合法子数组个数。

哈希表在这里派上用场：
• 边遍历边记录每个前缀和值出现的次数；
• 每次算出target = preSum[i+1] - k，查表里target出现几次就累加几次；
• 别忘了初始化：插入preSum[0]=0，次数为1（对应空前缀，支持从头开始的子数组）。

核心是：这一步避免了嵌套循环遍历j，把O(n)的查找压缩成平均O(1)的哈希操作。

实战细节：三个容易踩的坑

真正写代码时，这几个小细节往往导致结果偏差或逻辑错误：
• 哈希表必须先查后插：确保j严格小于当前i，不能先把自己刚算出的preSum[i+1]记进去，否则会匹配到自身，引入长度为0的子数组；
• preSum长度调整为n+1：索引0到n共n+1个值，对应空前缀到全长前缀；
• 注意整型溢出：在Ja va或C++里，数组特别长、数值特别大时，前缀和可能超出int范围，建议用long；Python自动处理，但逻辑一致性仍需检查。

一个典型错误写法：
先执行map.put(preSum[i+1], ...)，再查询target → 结果里包含长度为0的子数组或下标顺序错误，整个统计全盘错乱。

暴力法与优化法的真实差距

拿n=10⁵的数组来测：
• 暴力双循环：约50亿次加法和判断，普通机器上跑超过10秒；
• 前缀和+哈希：10⁵次加法+10⁵次哈希操作，10毫秒内完成。

更关键的是可扩展性：
• 暴力法在n=10⁶时就基本不可用；
• 优化法处理百万级数据依然稳定——这也正是为什么它在日志分析、实时风控、滑动窗口统计这类真实业务场景里，是更合适的选型。