每天用着的SUMIF把我坑惨了，原来你是最熟悉的陌生人
👍
近期推送的文章
· 正 · 文 · 来 · 啦 ·
正餐前的开胃菜：
SUMIF，相信大部分人都用过，并且已经很熟悉了，but，它城府很深、老谋深算、老奸巨滑，将自己的一些臭毛病隐藏得很深很深，你稍不留意，你被坑得很惨很惨。
我们来看看它有哪些臭毛病：
臭毛病一：盲目排外
SUMIF只认自己人（本工作簿），以及对自己开放的人（其他处于打开状态的工作簿）。如果你对它关上大门，它立马变脸。
比如下表，对另一个工作簿《A公司销售统计表》进行条件统计，当《A公司销售统计表》工作簿打开时，公式没问题:
下次再打开时，如果没打开源数据表格《A公司销售统计表》，就会显示错误：
这毛病，坑人无数！位列第一
与SUMIF一样有这个臭毛病的函数还有：
INDIRECT函数；
SUMIFS、 COUNTIF、 COUNTIFS 、COUNTBLANK 函数等；
D字头的数据库函数：DAVERAGE、 DCOUNT、 DCOUNTA、 DGET、 DMAX……等
解决方案：
使用没这个臭毛病的函数，比如SUMPRODUCT函数，来条件求和。
请参阅：
臭毛病二：自以为是、自作多情
SUMIF函数还有自以为是的毛病：会自动将类数字文本当成数字处理。它这个毛病经常在下面4种情形下给我们挖坑：
1、文本类数字只认前十五位
只要前十五位相同，它就认为是一样的。
原因及解决方案：
奇怪，用SUMIF对超15位的代码进行条件求和，居然出错了，原因是....
2、对文本类的2020.1、2020.10以及数字2020.1都自以为是的当成数字2020.1
解决方案：
参见上一小点
3、对前缀0视而不见
4、对日期类文本自作聪明的以为是日期
比如下图C列、F列均为文本格式，但SUMIF都会自动将2020年1月视为2020年1月1日（类似于在单元格输入2020年1月，会自动变为2020年1月1日）
当然，这也不全是毛病，比如在条件中将文本类的日期写入公式中，SUMIF会自动将其变成日期，但SUMPRODUCT必须得运算一下才行：
臭毛病三：鸡肠小肚
SUMIF除了前面的盲目排外、自以为是，还特别鸡肠小肚，条件区域的字符超255个就罢工：
详细情况请参阅：