Excel SUM家族函数全解析：从SUMIFS到SUMPRODUCT的求和避坑指南

“SUM系列函数”这几个字，几乎是每个人打开 Excel 后学到的第一组函数。但我在实际协作中反复看到一个现象：真正把这套函数用对、用稳的人并不多。多数人的水平停留在点一下“自动求和”按钮，稍微复杂一点就靠辅助列堆、靠手工挑，或者干脆把数据导到别处再算一遍。问题不在于函数难，而在于 SUM 家族有六七个长得很像的成员，参数顺序、过滤规则、对文本和错误值的态度各不相同，用错一个参数，结果就可能悄悄差出一大截，而且不报错。

这篇内容想做的事很具体：把 SUM、SUMIF、SUMIFS、SUMPRODUCT、SUBTOTAL、AGGREGATE 这几个函数放在一起，按“它们各自解决了什么维度的需求”重新梳理一遍，把参数顺序、条件写法、尺寸匹配、精度误差、可见行统计这些容易踩的点讲透。适合两类人看：一类是刚接触 Excel、只会点自动求和的新手，看完能明白每个函数该在什么场合出场；另一类是天天跟报表打交道、但一直被“求和结果对不上”折磨的人，看完能拿到一份可直接抄的排查清单。

1. 先把SUM家族认全：一个求和需求为什么被拆成七八个函数

1.1 从“加一下”到“按条件加一下”的需求分层

求和这个动作本身没有难度，难度全在“加哪些”。你手上的数据一旦带上维度，需求就会自动分层：最上面一层是“全部加起来”，这是 SUM 的地盘；往下走一层是“只加某一类”，比如只看某个部门、某个月份，这是 SUMIF 和 SUMIFS 的战场；再往下一层是“只加眼睛能看见的”，也就是筛选之后剩下的那些行，这是 SUBTOTAL 和 AGGREGATE 的价值；还有一层是“加的时候顺便做个乘法”，比如数量乘单价再汇总，SUMPRODUCT 就是为这个场景准备的。

这四层需求对应四种完全不同的过滤逻辑：无条件、按单元格值过滤、按显示状态过滤、按数组运算过滤。Excel 把它们拆成独立函数，是因为每种过滤逻辑要处理的边界情况完全不同。SUMIFS 需要处理通配符和比较运算符，SUBTOTAL 需要判断行是不是被筛选隐藏，SUMPRODUCT 需要处理数组维度对齐。硬塞进一个函数里，参数会长到没法用。

理解这一点很关键。很多人在写公式时纠结“到底该用哪个”，其实只要先问自己一句：我要过滤的是值，还是显示状态？答案立刻就清楚了。

1.2 六个核心成员的分工对照表

我习惯用一张表把这几个函数摆在一起看，比翻帮助文档快得多。

这张表里最容易被忽略的是最后一列“内置的特殊过滤”。它决定了你在什么情况下必须换函数：只要你的数据里存在被筛选掉的行，SUM 就会把它们一起加进去，这时候无论条件写得多漂亮都没用，必须换 SUBTOTAL；只要你的数据里存在错误值，SUM 和 SUMIFS 都会直接返回错误，这时候得靠 AGGREGATE 或者先用 IFERROR 洗一遍数据。

提示：不要试图用一个“万能函数”解决所有求和问题。实际项目里最常见的错误不是函数选错，而是选对了函数却用错了参数顺序。

2. SUM本身：最没技术含量，坑却最多

2.1 区域引用、直接参数、三维引用三种写法

SUM 的语法简单到没什么可讲的：SUM(number1, [number2], ...)，最多 255 个参数。但参数的“形态”有三种，行为差别不小。

第一种是区域引用，=SUM(B2:B100)，这是最常见的写法，Excel 会遍历整个区域把数值加起来。第二种是直接参数，=SUM(B2, B5, B9)，或者干脆写常量=SUM(1, 2, 3)。第三种是三维引用，=SUM(一月:三月!B2)，把多张工作表的同一个单元格加在一起，做季度汇总、多门店汇总时特别省事。

三维引用有个前提：参与的工作表必须在标签栏里连续排列，中间不能夹着汇总表或者说明页。如果结构允许，我更推荐把各月数据放在同一张表里用一列“月份”区分，然后用 SUMIFS 汇总，这样新增月份不用改公式，也不会因为插入工作表把引用范围搞乱。

=SUM(一月:三月!B2) ' 三维引用，求和三张表同一位置 =SUM(B2:B100) ' 常规区域 =SUM(B2, B5, B9) ' 离散单元格

2.2 文本数字、逻辑值、错误值在SUM里的三种待遇

SUM 对数据类型的态度很不一致，这是很多“求和结果偏小”问题的根源。

区域引用里的文本会被直接忽略。假设 B2:B4 里分别是数字 100、文本“200”、数字 300，=SUM(B2:B4)的结果是 400，那个长得像数字的文本被跳过了，而且不会有任何提示。这类数据通常来自系统导出，单元格左上角带个绿色小三角，或者用=ISTEXT(B2)能返回 TRUE。处理办法是选中整列，用“数据-分列”直接点完成，或者用=SUM(--B2:B4)这类数组写法强转，但后者在旧版本需要按 Ctrl+Shift+Enter。

逻辑值在区域里同样被忽略，但作为直接参数时会被转换。=SUM(TRUE, FALSE)返回 1，而如果 A1 是 TRUE，=SUM(A1:A1)返回 0。这个差异在实际使用中很少碰到，但在写嵌套公式时容易翻车。

错误值则是另一回事：区域内只要有一个#N/A或#DIV/0!，整个 SUM 就返回同样的错误。这不是 bug，是设计上的“错误传播”。如果你的源数据里必然存在查不到的情况，要么在源头用 IFERROR 包住，要么汇总时改用 AGGREGATE。

注意：SUM 忽略文本数字这件事不会给出任何警告。做对账时如果发现合计比明细少，第一件事就是检查那一列的数据类型。

2.3 自动求和按钮与Alt+=背后的行为

工具栏上那个“自动求和”按钮，以及快捷键 Alt+=，本质上就是帮你插入一个 SUM 公式。它会向上、向左寻找连续的数据区域，找到边界后自动填入引用。这个智能判断在规整的表格里很好用，但在有空行、有合并单元格、或者上方是标题行的情况下，选中范围经常是错的。

我自己的习惯是：先用 Alt+= 快速生成，然后立刻按 F2 进编辑状态，用鼠标重新框一遍范围，或者直接把引用改成整列、改成结构化引用。多花三秒钟，能省掉后面半小时的排查。

还有一个细节值得说：Alt+= 在选中一整行或一整列时会自动在末尾追加合计，选中一个区域时会在区域下方和右侧同时生成行合计与列合计。做交叉表的时候，这个操作比手写公式快得多。

3. SUMIF与SUMIFS：参数顺序这件事，值得单独讲一节

3.1 为什么SUMIF是“先范围后求和”，SUMIFS是反的

这是 SUM 家族里最经典的记忆负担。

SUMIF(range, criteria, [sum_range]) SUMIFS(sum_range, criteria_range1, criteria1, [criteria_range2, criteria2], ...)

SUMIF 的顺序是“条件区域在前，求和区域在后”；SUMIFS 的顺序是“求和区域在前，条件区域在后”。这不是设计者故意为难人，而是历史原因：SUMIF 诞生得早，当时的思路是“我给你一个范围，你按条件挑”，求和区域是可选参数；SUMIFS 是后来为了多条件补充的，为了让参数可以无限扩展，必须把唯一的“求和区域”放在最前面固定住，后面成对追加条件。

记忆方法我自己用的是一个笨办法：SUMIF 只有一个条件，条件区域是主角，所以放第一位；SUMIFS 有多个条件，条件区域会重复出现，主角只能是求和区域，所以放第一位。写着写着就顺了。

省略 sum_range 时，SUMIF 会对 range 本身求和。这个特性在“统计某列中大于 0 的数值之和”这种场景下很方便，=SUMIF(B2:B100, ">0")就够了。但很多人会误以为 SUMIFS 也能这么省——不行，SUMIFS 的 sum_range 是必填的。

3.2 条件表达式怎么写才不出错

criteria 这个参数看起来是个字符串，实际上它是一套小型表达式语法，规则比想象中严格。

比较运算符必须用英文双引号包起来，比如">100"、"<>"、">=2024-1-1"。如果比较的值来自另一个单元格，要用&拼接：">="&D2。直接写">=D2"会被当成文本比较，结果永远是 0，而且不报错——这是最高频的隐性错误之一。

通配符方面，*代表任意多个字符，?代表单个字符，~用来转义。=SUMIF(A:A, "华*", B:B)会匹配所有以“华”开头的内容。这里有个坑：*和?只对文本生效，如果条件区域里存的是数字，通配符不起作用。另外，如果数据本身包含*或?字符（比如产品型号），需要写成"A~*B"才能精确匹配。

日期条件是最容易出问题的地方。">=2024-1-1"这种写法在某些区域设置下会被解析成文本，稳妥的写法是用 DATE 函数拼接：">="&DATE(2024,1,1)。如果日期在某个单元格里，">="&D2也可以，但要确保 D2 是真正的日期值而不是文本。

文本比较默认不区分大小写，"apple"和"APPLE"会被视为相等。如果需要精确区分，得用 SUMPRODUCT 配合 EXACT 函数，SUMIFS 做不到。

=SUMIF(A:A, "华*", B:B) ' 文本前缀匹配 =SUMIF(B:B, ">="&D2, C:C) ' 比较值来自单元格 =SUMIFS(C:C, A:A, "华北", B:B, ">="&DATE(2024,1,1), B:B, "<="&DATE(2024,3,31))

3.3 sum_range与range尺寸不一致时的错位灾难

这是 SUMIF 独有的坑，SUMIFS 反而没有（因为 SUMIFS 要求所有区域尺寸严格一致，否则直接报#VALUE!）。

SUMIF 允许 range 和 sum_range 尺寸不同。它的处理方式是：以 sum_range 的左上角单元格为起点，按照 range 的形状和大小向外扩展，扩展出来的区域才是真正参与求和的范围。也就是说，你写的 sum_range 只决定了“从哪里开始”，不决定“到哪里结束”。

举个具体例子：=SUMIF(A2:A10, "华北", B2)。range 是 9 行 1 列，sum_range 只写了 B2 一个单元格。Excel 会自动把 B2 扩展成 B2:B10，结果是对的。但如果写成=SUMIF(A2:A10, "华北", B2:B5)，它仍然会扩展到 B2:B10，你写的 B5 这个上界被无视了。更危险的情况是 range 和 sum_range 的列偏移写错了，比如=SUMIF(A2:A10, "华北", A2:A10)本来想对 B 列求和，结果求的是 A 列自己的和，因为 A 列是文本，结果直接是 0。

我的做法是永远让两个区域保持完全对称：要么都写整列A:A和B:B，要么都写$A$2:$A$1000和$B$2:$B$1000，绝不给 Excel 自动扩展的机会。

3.4 多条件AND与OR：数组常量和SUM嵌套

SUMIFS 的多组条件之间是 AND 关系，全部满足才计入。想要 OR 关系，光靠 SUMIFS 做不到，得借助数组。

最常用的写法是把 SUMIFS 包在 SUM 里，用数组常量作为条件：

=SUM(SUMIFS(C:C, A:A, {"华北","华南","华东"}))

这里 SUMIFS 会对数组里的每个值分别算一次，返回三个结果，外层 SUM 再把它们加起来。注意这个写法在逻辑上是“或”，但要求三个条件互斥，否则同一行会被重复计算。如果条件可能重叠，得先去重。

另一种 OR 写法是 SUMPRODUCT：

=SUMPRODUCT(((A2:A100="华北")+(A2:A100="华南"))*(C2:C100))

这里两个布尔数组相加，满足任一条件的位置会得到 1，两个都满足会得到 2，所以如果两个条件可能同时成立，必须写成--((条件1)+(条件2)>0)来归一化。这个细节在跨类别统计时特别容易出错，我第一次用的时候就因为一个客户同时属于两个标签，导致金额被算了两遍。

4. SUMPRODUCT：把求和升级成矩阵运算

4.1 数组相乘的原理与维度对齐

SUMPRODUCT 的官方定义是“返回相应数组或区域的乘积之和”，翻成大白话就是：把几个数组对应位置的元素先相乘，再把所有乘积加起来。

=SUMPRODUCT(B2:B10, C2:C10)

这等价于B2*C2 + B3*C3 + ... + B10*C10。它最常见的用途是算加权金额：B 列是数量，C 列是单价，一次就出总金额，不需要辅助列 D 列先算B*C再 SUM。

它有一个硬性约束：所有数组的维度必须完全一致，行数和列数都要对得上，否则直接返回#VALUE!。这一点比 SUMIFS 严格得多，好处是错误会立刻暴露，坏处是写公式时要格外注意区域对齐。

SUMPRODUCT 真正的威力在于，它允许你在数组里做布尔运算。比较表达式A2:A10="华北"会返回一组 TRUE/FALSE，乘以 1 或者用双负号--转换后变成 1/0，再和其他数组相乘，就实现了“条件筛选 + 求和”一步到位。

=SUMPRODUCT((A2:A100="华北")*(B2:B100="A类")*C2:C100)

这行的含义是：A 列等于华北 且 B 列等于 A 类 的行，把 C 列的值加起来。两个条件之间用*，天然就是 AND 关系。

4.2 用SUMPRODUCT替代辅助列做多条件统计

在 SUMIFS 出现之前，SUMPRODUCT 是多条件求和的唯一选择，现在它依然在两个场景下不可替代。

第一个场景是条件里包含函数运算。SUMIFS 的条件只能基于单元格原值做比较，没法对单元格先做处理再比较。比如要统计“长度大于 5 的产品编号对应的金额”，SUMIFS 写不出来，SUMPRODUCT 可以：

=SUMPRODUCT((LEN(A2:A100)>5)*C2:C100)

第二个场景是条件之间存在 OR 且可能重叠。前面提过，用+连接布尔数组再判断>0，这是 SUMIFS 做不到的。

第三个场景是统计满足条件的“行数”而不是求和。把最后的求和数组换成 1，就变成了条件计数：

=SUMPRODUCT(--(A2:A100="华北"))

效果和 COUNTIF 一样，但在条件复杂时更灵活。

需要提醒的是，SUMPRODUCT 里的布尔转换不能省。如果直接写(A2:A100="华北")*C2:C100，Excel 在运算时会自动把 TRUE/FALSE 转成 1/0，多数情况下没问题。但如果只有一个条件且没有乘法运算，比如=SUMPRODUCT(A2:A100="华北")，它会返回 0，因为 SUMPRODUCT 只有一个参数时不会做乘积，TRUE/FALSE 也不会被转换。这种写法必须加--。

4.3 与SUMIFS的分工：什么时候该用谁

两者的功能有重叠，选型主要看三点：条件复杂度、数据量、可维护性。

条件全部是“某列等于/大于/包含某个值”这种简单比较，优先 SUMIFS。它内部有针对索引的优化，即使引用整列也很快，而且语法直白，别人接手容易看懂。

条件里需要函数运算、需要 OR 且可能重叠、需要做加权计算，用 SUMPRODUCT。它的代价是全数组运算，引用A:A这种整列会真的去算一百多万行，表格稍微复杂一点就会明显卡顿。

数据量方面给个参考：几万行以内，两者差别不明显；超过十万行，SUMPRODUCT 用整列引用基本等于自找麻烦，务必把范围收窄到实际数据区间，或者改用表格结构化引用。

5. 可见单元格求和：SUBTOTAL与AGGREGATE

5.1 SUBTOTAL的1-11与101-111到底差在哪

SUBTOTAL 的语法是SUBTOTAL(function_num, ref1, [ref2], ...)，第一个参数不是求和范围，而是一个编号，用来指定“你要做哪种统计”。1 到 11 对应 AVERAGE、COUNT、COUNTA、MAX、MIN、PRODUCT、STDEV.S、STDEV.P、SUM、VAR.S、VAR.P，其中 9 就是 SUM。

101 到 111 是同一组功能的另一套编号，区别只有一个：是否忽略手动隐藏的行。

• =SUBTOTAL(9, B2:B100)：忽略被筛选隐藏的行，但手动右键隐藏的行仍然参与计算。
• =SUBTOTAL(109, B2:B100)：筛选隐藏和手动隐藏的行都不参与计算。

这个区别在实操中非常关键。如果你做了一个带筛选的明细表，底部放SUBTOTAL(9, ...)，用户筛选后合计会跟着变，看起来很正常。但如果用户又手动隐藏了几行（比如临时不想看某些数据），SUBTOTAL(9, ...)仍然会把它们算进去，用户就会觉得“数字不对”。用 109 可以避免这个困惑，代价是手动隐藏的数据也被排除了，需要跟使用者说清楚。

SUBTOTAL 还有两个隐藏特性值得记住。第一，它会自动跳过区域内嵌套的其他 SUBTOTAL 结果，所以在分组小计的表里，用 SUBTOTAL 做大合计不会把小计重复加一遍——这是 SUM 做不到的。第二，它对区域内的文本和逻辑值同样忽略，行为和 SUM 一致。

注意：SUBTOTAL 只能识别“筛选”和“手动隐藏”这两种状态。如果行是因为分组折叠（数据-创建组）而收起的，行为需要实测确认，不同版本表现可能不同，别把它当成稳定特性来用。

5.2 AGGREGATE的错误值豁免与隐藏行选项

AGGREGATE 是 SUBTOTAL 的加强版，语法AGGREGATE(function_num, options, ref1, [ref2], ...)。function_num 扩展到 1 到 19，除了常规统计还包含 LARGE、SMALL、PERCENTILE、QUARTILE、MODE 等，求和仍然是 9。

真正的差异在第二个参数 options，它用 0 到 7 八个编号控制“忽略什么”：

最常用的组合是AGGREGATE(9, 6, ...)和AGGREGATE(9, 3, ...)。前者只处理错误值，不管隐藏；后者把隐藏行和错误值一起处理掉。

它的典型战场是源数据里必然存在错误值的情况。比如用 VLOOKUP 从另一张表匹配单价，匹配不到会返回#N/A，直接 SUM 整列会炸，AGGREGATE(9, 6, C2:C1000)就能安安稳稳地给出正确合计，不需要先插一列 IFERROR 洗数据。这在临时分析、不想改动原始表结构的时候特别好用。

=AGGREGATE(9, 6, C2:C1000) ' 忽略错误值求和 =AGGREGATE(9, 3, C2:C1000) ' 忽略隐藏行和错误值求和

5.3 筛选、手动隐藏、分组隐藏的区别

这三种“看不见”的状态在 Excel 里是完全不同的机制，直接影响合计公式的选择。

筛选是通过列头上的筛选器控制行的显示，被筛掉的行Hidden属性为 TRUE，SUBTOTAL 和 AGGREGATE 的隐藏行选项都能识别。

手动隐藏是选中行后右键“隐藏”，行高变为 0，Hidden属性同样为 TRUE，SUBTOTAL(109, ...)和AGGREGATE的隐藏行选项能识别，但SUBTOTAL(9, ...)不识别。

分组折叠是通过“数据-创建组”实现的，它本质上也是一种隐藏，但在某些版本里和筛选隐藏的判定路径不同。我个人的经验是不要依赖公式去判断分组状态，如果报表需要分组折叠，宁可在大合计里用SUBTOTAL(109, ...)并提前说明规则。

还有一个容易被忽略的场景：复制粘贴。当你筛选后复制可见单元格，Excel 默认只复制可见部分；但如果直接 Ctrl+C 再粘贴到新表，隐藏行也会被带过去。正确做法是按 Alt+; 选中可见单元格再复制。这个操作和求和公式无关，但在做汇总表时经常一起出现。

6. 精度、性能与动态区间：实战里绕不开的三道坎

6.1 浮点误差：为什么0.1+0.2不等于0.3

Excel 用二进制浮点数存储小数，某些十进制小数无法精确表示，累加之后就会出现极小的尾差。这是所有电子表格软件的共性，不是 Excel 的缺陷，但它确实会让对账工作变得很难受。

=SUM(0.1, 0.2) ' 显示 0.3，实际值 0.30000000000000004 =SUM(0.1, 0.2)=0.3 ' 返回 FALSE =ROUND(SUM(0.1,0.2),2)=0.3 ' 返回 TRUE

在金额场景里，这种尾差通常表现为“合计比明细少一分钱”或者“两个表对不上”。我看过一个很典型的例子：一百多笔金额累加，每笔都是两位小数，SUM 出来的结果和另外一张表差了 0.01。逐笔核对完全一致，最后发现就是浮点累加造成的。

处理办法有三个层次。最稳妥的是在求和外套一层 ROUND：=ROUND(SUM(B2:B100), 2)，把结果强制收敛到两位小数。第二种是从源头控制，输入时就保证是两位小数，避免出现 0.1+0.2 这种无限循环的场景。第三种是接受它，但在报表上明确标注“合计存在分位误差，以明细为准”，避免下游反复追问。

还有一点：Excel 只保留 15 位有效数字。超过 15 位的数字（比如某些长编号）在输入时就会被截断成 0，这时候它已经不是数值了，不该用 SUM 去加，应该当作文本处理。

6.2 整列引用与易失性函数带来的卡顿

A:A这种整列引用写起来爽，代价是 Excel 要处理 1048576 行。SUM 和 SUMIFS 内部有优化，通常感觉不到卡；SUMPRODUCT 没有这层优化，整列引用会让它实打实地遍历一百多万行，几万行数据就开始有明显延迟。

比整列引用更隐蔽的是易失性函数。OFFSET、INDIRECT、TODAY、NOW、RAND、RANDBETWEEN 这些函数，只要工作簿里任何地方发生变化，它们就会重新计算。如果 SUM 的范围是用 OFFSET 动态生成的，那么这个 SUM 会跟着全表重算，表一大就卡得没法用。

替代方案有两个。一是用 INDEX 构造动态区间：

=SUM(INDEX(B:B,2):INDEX(B:B,1000))

INDEX 不是易失性函数，只有引用变化时才重算，性能好很多。

二是用表格（Ctrl+T）的结构化引用，=SUM(表1[金额])，新增行会自动扩展范围，公式不用改，也不会拖慢计算。

排查卡顿还有一个实用技巧：把计算模式临时改成“手动”（公式-计算选项-手动），然后按 F9 逐段重算，看是哪一片区域拖慢的。这个办法比盯着屏幕猜有效得多。

6.3 累计求和、动态区间与“求和结果对不上”排查清单

累计求和是最常见的动态区间需求。B 列是每日金额，想要 C 列显示“从第一天到当天”的累计：

=SUM($B$2:B2)

关键在于起始行用绝对引用$B$2，结束行用相对引用B2，向下填充时区间会自动拉长。这个写法的成本很低，但数据量超过几万行时会明显变慢，因为每一行都要重新遍历一次区间。数据量大时改用=SUMIF($A$2:A2, "<="&A2, $B$2:B2)或者直接用数据透视表的“按行累计”更快。

动态区间还有一种做法是用 SUMIFS 配合起止日期，比 OFFSET 稳定得多：

=SUMIFS(C:C, A:A, ">="&G2, A:A, "<="&H2)

G2 和 H2 是起止日期，改日期就改区间，公式本身不动。这种写法在搭建可交互的汇总面板时特别顺手。

至于“求和结果对不上”，我整理了一份按优先级排序的排查清单，基本上能覆盖九成以上的情况：

这张表建议打印出来贴在显示器旁边。我遇到过的问题里，排前三的永远是文本型数字、筛选隐藏行和 SUMPRODUCT 忘加--。

7. 常见问题速查与几条踩坑心得

7.1 高频问题速查表

把日常被问得最多的几个问题集中列一下，方便对照。

7.2 我个人的几条使用习惯

写公式这件事，风格比技巧更影响长期效率。分享几个我坚持了很多年的习惯。

第一个习惯是永远不用合并单元格存数据。合并单元格只有左上角有值，其他位置是空的，SUM 求和时会漏掉，筛选时也会出各种怪问题。需要视觉上的合并效果，用“跨列居中”代替，数据该在哪一格就在哪一格。

第二个习惯是公式里的区域尽量对称。SUMIFS 的求和区域和条件区域，要么都写整列，要么都写死区间，绝不允许一个整列一个局部。这个规则看起来死板，但能挡掉至少一半的错位问题。

第三个习惯是给关键汇总加校验行。比如明细表底部放一个=SUM(B2:B1000)，汇总表里对应的位置放=SUMIFS(...)，再单独加一格=SUM(B2:B1000)-SUMIFS(...)，正常应该是 0。这个差值格平时不显眼，一旦不为 0 就说明有数据落在条件之外了，比事后逐笔核对快得多。

第四个习惯是把复杂条件拆开验证。写一个多条件 SUMIFS 之前，先用 COUNTIFS 数一下有多少行满足，确认数量对得上再求和。数量不对说明条件写错了，这时候看金额是看不出问题的。

第五个习惯是临时分析用 SUMPRODUCT，正式报表用 SUMIFS。前者灵活，随手就能改条件；后者稳定，交接给别人不容易被改坏。

提示：所有求和公式写完后，养成按 Ctrl+`（反引号）切换显示公式模式的习惯，扫一眼整张表的公式结构，能快速发现引用错位、区域不一致这类肉眼难察觉的问题。

最后说个我自己踩过的坑。早年做一张按部门汇总的表，用 SUMIF 写了几十行，结果有一个部门的数字总是偏大。查了很久才发现，那个部门的名称在源数据里有两种写法，一种带空格一种不带，而我在条件里写的是不带空格的那个。SUMIF 的文本比较是精确匹配（通配符除外），一个看不见的空格就能让结果天差地别。从那以后，我处理任何带文本条件的求和之前，都会先对条件列做一次 TRIM 清洗，或者用=SUMPRODUCT((TRIM(A2:A100)="华北")*C2:C100)在公式里直接处理。多写几个字符，省下的是整晚的排查时间。