前缀和数组需初始化长度为n+1、首项为0，递推式为prefixsum[i+1] = prefixsum[i] + nums[i]；查询[l,r]用prefixsum[r+1]-prefixsum[l]；不支持高效单点修改，动态场景应换树状数组或线段树。
怎么快速实现前缀和数组（prefixSum）
Go 里没有内置前缀和类型，必须手动构建。核心就一行逻辑：prefixSum[i+1] = prefixSum[i] + nums[i]，注意长度比原数组多 1，这样能统一处理边界（比如 sumRange(0, j) 不用特判）。别直接改原数组，也别从 i=0 开始填 prefixSum[0] ——它必须是 0。
- 初始化
prefixSum := make([]int, len(nums)+1)，不是len(nums) - 循环下标用
i从0到len(nums)-1，对应填入prefixSum[i+1] - 查询
[l, r]时，直接返回prefixSum[r+1] - prefixSum[l]，无需 if 判断 l 是否为 0
为什么区间求和要写成 prefixSum[r+1] - prefixSum[l]
因为 prefixSum[i] 定义为「前 i 个元素之和」，即 nums[0..i-1] 的和。所以 prefixSum[r+1] 是 nums[0..r] 和，prefixSum[l] 是 nums[0..l-1] 和，相减自然得 nums[l..r]。如果定义成「到下标 i 的和」，反而会让所有查询多一次边界检查，还容易索引越界。
- 错误写法：
prefixSum[i] = prefixSum[i-1] + nums[i]（i=0 会 panic） - 错误理解：
prefixSum[3]表示前三项和 → 正确；表示nums[3]的前缀和 → 错误 - 这个定义让
sumRange(0,0)变成prefixSum[1]-prefixSum[0]，安全且直观
频繁单点修改时，还能用前缀和吗
不能。前缀和本质是静态预处理结构，一旦 nums[i] 改变，从 i+1 开始的所有 prefixSum 都得重算，最坏 O(n)。这时候该换 fenwick tree（树状数组）或 segment tree（线段树）。
- 适用场景：多次查询、几乎不修改（如 LeetCode
NumArray题） - 不适用场景：边改边查（如实时弹幕计数、滑动窗口动态更新）
- 若只有末尾追加，可增量更新
prefixSum，但中间插入/删除仍不行
字符串前缀匹配和前缀和有关系吗
完全无关。名字都带“前缀”，但一个是数值累加（prefixSum），一个是字符串公共开头（lcp）、或是数据结构（Trie）。有人看到 prefix 就想套用前缀和模板，结果在字符串题里硬造一个 int 数组去“求和”，纯属混淆概念。
-
lcp(s, t string)是逐字符比较，返回 int 长度，不是查表 -
Trie存的是字符路径，不是数字累积 - 真正容易混的是
KMP的next数组（也叫前缀函数），但它算的是模式串自身的 border 长度，和前缀和算法毫无数学关联
前缀和看着简单，但下标偏移、定义一致性、适用边界这三点，实际写错率很高。尤其当需求从“只读查询”悄悄变成“带更新”，很多人还在死守 prefixSum，而不是立刻切换数据结构。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
