八道题，全部围绕「不报错却返回 0」的公式——正是这个失败模式让条件聚合变得危险。每组先讲成因，再给你一个公式去判断。
SUMIF 和 COUNTIF 有一个特性，使它们值得动手练而不是查一下就走：出错时它们不吭声。匹配不上任何东西的条件返回 0，而 0 看起来是个完全合理的合计。没人会发现，直到这个数字被报上去、有人问一句「怎么这么低」。
四个成因几乎解释了全部问题。SUMIF 与 SUMIFS 的参数顺序相反，所以一个读起来没错的公式，可能在判断错误的那一列。含运算符的条件必须加引号，引用单元格的条件必须用 & 拼接。复数形式的条件之间取「且」、且没有「或」，这就是为什么日期区间要写两个条件、而「North 或 South」要写两个公式。而以文本形式存储的数字——CSV 导入的标准产物——永远满足不了数值条件。
下面的内容在 Microsoft 365、Excel 2021 及较新版本中行为一致，同样的规则也适用于 AVERAGEIF 与 AVERAGEIFS。每题先自己判断，再看答案。
这两个函数的参数顺序正好相反，而且这属于历史遗留的疙瘩、推不出来：SUMIF 是（区域, 条件, [求和区域]），SUMIFS 是（求和区域, 条件区域, 条件, …）。既然 SUMIFS 处理单条件毫无问题，最省事的策略就是一律用 SUMIFS，从此不用再想另一种顺序。COUNTIF 和 COUNTIFS 没这个问题——它们都不需要单独的求和区域。
通常怎么表现：「SUMIF 和 SUMIFS 有什么区别」·「我的 SUMIF 为什么返回 0？」
第 1 题
B 列是地区、C 列是金额。你想求 North 地区的合计。哪个公式是对的？
=SUMIF(B2:B100, "North", C2:C100)
=SUMIF(C2:C100, "North", B2:B100)正确答案：B. 第一个——SUMIF 是先给要判断的区域、再给条件、最后给要相加的区域
🐱 SUMIF 用条件去检查第一个区域，再把命中行对应的第三个区域的值加起来。第二个公式是拿文本 "North" 去金额列里找，一个也找不到，于是返回 0——不报错，只是给你一个看起来像真答案的错合计。这个静默的 0，正是条件聚合里代价最高的新手错误。
第 2 题
你要求「既在 North 地区、金额又大于 500」的销售合计。哪个可行？
=SUMIFS(C2:C100, B2:B100, "North", C2:C100, ">500")
=SUMIF(B2:B100, "North", C2:C100) + SUMIF(C2:C100, ">500", C2:C100)正确答案：B. 第一个——SUMIFS 把所有条件应用在同一行上；两个 SUMIF 相加会重复计数，而且回答的是另一个问题
🐱 多条件的含义是「同一行同时满足」，这正是 SUMIFS 做的事。两个 SUMIF 相加算的是「North 合计」加「大于 500 合计」——North 里大于 500 的那些被数了两遍，而 North 之外大于 500 的也被算了进来。凡是发现自己在把几个条件求和相加，答案几乎总是改用一个 SUMIFS。
条件里含运算符时必须写在引号内：">100"、"<>North"；值在单元格里时写 ">="&A2。不加引号的 >100 是语法错误，而不加连接符的 A2 会被当成字面文本比较。文本条件支持通配符——"North*" 匹配所有以 North 开头的、"?ast" 能同时匹配 East 和 West——这有时正是你要的，有时正是合计偏大的原因。
通常怎么表现：「SUMIF 里大于号怎么写？」·「我的条件为什么一个都匹配不上？」
第 3 题
阈值存在单元格 F1 里。哪种条件写法是对的？
=SUMIF(C2:C100, ">F1", C2:C100)
=SUMIF(C2:C100, ">"&F1, C2:C100)正确答案：B. 第二个——运算符必须用 & 与单元格的值拼接，否则 Excel 拿它跟字面文本 "F1" 比较
🐱 在带引号的条件字符串里，F1 只是两个字符、不是引用——所以 ">F1" 问的是「大于文本 F1 的值」，数字永远不满足，于是返回 0。用 & 拼接会在计算时生成 ">500" 这样的字符串，才是你的本意。同样的写法适用于 COUNTIF、AVERAGEIF 及它们的复数形式。
第 4 题
A 列里既有 "North"，也有 "Northeast" 和 "Northwest"。这个公式数出多少个？
=COUNTIF(A2:A100, "North*")正确答案：B. 三种全数——星号是通配符，匹配 North 后面的任意字符
🐱 文本条件支持通配符：* 代表任意多个字符，? 代表恰好一个字符。所以 "North*" 会把 Northeast 和 Northwest 一并扫进来——这是计数结果比预期偏大的常见原因。要精确匹配就写不带通配符的 "North"；要匹配字面的星号，用 ~* 转义。
你每给 COUNTIFS 或 SUMIFS 加一对条件，结果只会变窄，因为这些条件是在同一行上取「且」——没有「或」的开关。这一个事实就解释了大家问得最多的三个问题：统计两个日期之间，意味着在同一列上写两个条件，而不是一个条件里塞一个区间；统计「North 或 South」根本不可能用一个 COUNTIFS 完成；而每个条件区域的行列数必须与第一个一致，否则你会拿到 #VALUE! 而不是一个错误的数字——这是这类函数唯一会出声警告你的场合。
通常怎么表现：「COUNTIFS 统计两个日期之间」·「COUNTIFS 怎么写「或」」·「COUNTIFS 为什么报 #VALUE!？」
第 5 题
A 列是日期。你想统计落在 2026 年第一季度的行数。哪个公式做得到？
=COUNTIFS(A2:A100, ">=2026-01-01", A2:A100, "<=2026-03-31")
=COUNTIFS(A2:A100, "between 2026-01-01 and 2026-03-31")正确答案：B. 第一个——区间就是同一列上的两个条件，同一列可以写两次
🐱 没有「between」这个运算符，所以区间要拆成下界和上界两个条件，两个都指向同一列。同一列写两遍第一次见会觉得别扭，但这正是对的——条件之间取「且」，两个边界一交，就是你要的区间。更稳的习惯是把边界日期放进单元格再引用：">="&F1 和 "<="&F2，这样还能避开「引号里的日期字面量在不同区域设置的机器上怎么解析」这个歧义。
第 6 题
你想统计地区是 North 或 South 的行数。这个公式返回什么？
=COUNTIFS(B2:B100, "North", B2:B100, "South")正确答案：B. 0——条件之间取「且」，而没有哪个单元格能同时等于两者
🐱 COUNTIFS 没有「或」。两个条件必须在同一行上同时成立，而一个单元格不可能既是 North 又是 South，所以老实的结果是一个静默的 0——和本页其余部分是同一个失败模式。要「或」，就把几个 COUNTIF 相加：=COUNTIF(B2:B100,"North") + COUNTIF(B2:B100,"South")。注意这和前面那道 SUMIFS 的题正好互为镜像：把条件统计相加，对「或」是正确的、对「且」是错误的，能分清这两者就是全部的功夫。
第 7 题
数据从第 2 行开始。这个公式返回 #VALUE! 而不是一个数字。问题在哪？
=COUNTIFS(B2:B100, "North", C2:C99, ">500")正确答案：B. 两个条件区域大小不一致——99 行对 98 行
🐱 COUNTIFS 和 SUMIFS 里每个条件区域的行数列数都必须与第一个相同，因为函数是逐行齐步走地比对它们的。C2:C99 比 B2:B100 少一行，于是没有一致的行可供判断，Excel 抛出 #VALUE!。拖一下某个区域的手柄就很容易造出这种不齐，而值得注意的是：这是这一族里唯一会大声报错的错误——大小不一致给你错误提示，而类型不匹配、区域写反给你的是一个貌似合理的错数字。
条件类函数从不告诉你「一个都没匹配上」——它返回 0，而这和「合计确实为零」看起来一模一样。两个主因占绝大多数：类型不匹配（CSV 导入后数字变成文本，数值条件因此永不触发），以及不可见字符，通常是尾随空格或从网页粘来的不换行空格。两者都会让看上去完全一样的单元格表现得像不同的值。
通常怎么表现：「COUNTIF 返回 0，可我明明看得到符合的行」
第 8 题
金额是从 CSV 导入的，在单元格里靠左对齐。明明有很多值超过 500，这个公式却返回 0。为什么？
=COUNTIF(C2:C100, ">500")正确答案：B. 这些值是以文本存储的，而在这个比较里文本永远不会「大于」一个数字
🐱 靠左对齐就是那个视觉线索：Excel 默认把文本靠左、数字靠右，所以一整列靠左的数字其实是一整列文本。数值条件因此一个也匹配不上，返回一个静默的 0。要修的是数据不是公式——用默认设置走一遍分列，或者乘以 1，或者用选择性粘贴→乘。养成扫一眼对齐方向的习惯，一秒就能发现它。
SUMIFS 支持多条件，但实际差别在参数顺序：SUMIF 是（区域, 条件, 求和区域），SUMIFS 是（求和区域, 条件区域, 条件）。既然 SUMIFS 处理单条件也毫无问题，一律用它就只需要记一种顺序。
最常见的是求和区域与条件区域写反了、条件字符串写法不对（引用单元格却没用 & 拼接）、或者导入后数字变成了文本。先看单元格对齐方向——文本靠左，数字靠右。
把运算符和引用拼起来：">"&F1。写成 ">F1" 是在跟字面上那两个字符 F1 做比较，没有任何数字会大于它，于是返回 0。
支持，用在文本条件里：* 匹配任意多个字符，? 匹配恰好一个。所以 "North*" 会把 Northeast 和 Northwest 也数进去——这是计数偏大的常见原因。要匹配字面星号，用 ~* 转义。
在同一列上写两个条件——一个下界一个上界：=COUNTIFS(A2:A100,">="&F1,A2:A100,"<="&F2)。没有「between」运算符，同一列写两遍是对的，因为条件之间取「且」。把边界日期放进单元格再引用，还能避开「引号里的日期字面量在不同区域设置下怎么解析」的歧义。
不能。每加一对条件只会让结果更窄，所以 COUNTIFS(B:B,"North",B:B,"South") 返回 0——没有单元格能同时是两者。要「或」，把几个 COUNTIF 相加：=COUNTIF(B:B,"North")+COUNTIF(B:B,"South")。这与「且」的情形正好互为镜像：在「且」那边，把条件求和相加会重复计数，正确写法是一个 SUMIFS。
几乎总是因为条件区域大小不一致——比如 B2:B100 对 C2:C99。每个条件区域的行数列数都必须与第一个相同，因为函数是逐行齐步走地比对它们的。这是这一族里唯一会大声报错、而不是返回一个貌似合理的错数字的错误。
不能。条件函数读的是值，不是格式。要按颜色汇总，需要加一个辅助列把颜色代表的含义记录下来——而这本来就是更好的设计，因为含义从此变成了数据而不是装饰。