DAX搞崩过3次报表的人，才懂这3个过滤器的坑

去年帮一个电商团队复盘报表，发现他们的GMV（商品交易总额）环比数据永远对不上财务系统。排查了6小时，问题出在FILTER函数上——一个括号的位置，让整列数据都错了。

DAX（数据分析表达式）的过滤器逻辑，是Power BI里最容易埋雷的地方。很多人以为掌握了CALCULATE就通关了，结果在复杂模型里反复踩坑。这篇把三个最隐蔽的陷阱拆清楚。

陷阱一：FILTER不是"筛选"，是"复制一张表再筛选"

新手最容易误解FILTER的行为。写`FILTER(Sales, Sales[Amount] > 100)`时，直觉以为是"在Sales表里挑出大于100的行"，但DAX实际做的是：复制整张Sales表，然后返回符合条件的行。

这个区别在数据量大时直接决定性能生死。一个500万行的表，FILTER会生成500万行的临时副本。如果嵌套多层FILTER，内存爆炸是常态。

更隐蔽的是上下文问题。看这段代码：

`Total High Value = CALCULATE(SUM(Sales[Amount]), FILTER(Sales, Sales[Amount] > 100))`

看起来没问题？但如果放在按产品类别筛选的矩阵里，FILTER会忽略外部的类别筛选器——因为它复制的是整张Sales表，不是当前可见的行。结果就是在每个类别格子里，算的都是全表大于100的总和，而不是"这个类别里大于100的总和"。

修正方案是把外部上下文传进去：`FILTER(ALLSELECTED(Sales), ...)`，或者直接用`Sales[Amount] > 100`作为布尔条件，让CALCULATE自己处理上下文。

陷阱二：ALL系列函数，清空的范围比你以为的大

ALL、ALLEXCEPT、ALLSELECTED这三个函数，是控制筛选器移除的核心工具。但它们的"清除半径"经常被误读。

ALL(Table)会移除该表上所有列的筛选器，不只是你写度量值时用到的那几列。一个经典翻车场景：写了个`ALL(Customer)`来对比某个客户 vs 全体平均，结果报表上的日期筛选也失效了——因为Customer表和Date表有关联，ALL清空了Customer，连带影响了扩展表上的Date筛选。

ALLEXCEPT看起来是"保留某些列的筛选"，但它的逻辑是"清除除指定列外的所有筛选"。如果模型里有20列，你ALLEXCEPT了2列，剩下18列的筛选全丢。这在宽表里尤其危险。

ALLSELECTED是最常用的，但它的行为取决于计算发生的层级。在矩阵的总计行，ALLSELECTED返回的是该视觉对象上所有外部筛选的交集；在明细行，范围会收缩。同一个度量值，在不同层级可能算出完全不同的"总计"，这不是bug，是设计特性——但90%的人第一次遇到会以为是数据错了。

一个验证技巧：在度量值里加`VAR _currentContext = SUMMARIZECOLUMNS(...)`把当前可见行打出来，对比ALLSELECTED返回的集合，能快速定位范围偏差。

陷阱三：行上下文和筛选上下文，在迭代函数里打架

CALCULATE能转换行上下文为筛选上下文，这个特性是DAX的精髓，也是噩梦来源。

看这段代码意图：计算每个客户的首次购买日期。

`First Purchase = CALCULATE(MIN(Sales[Date]), FILTER(Sales, Sales[CustomerID] = Customer[CustomerID]))`

放在客户表的计算列里，结果全是空。问题出在FILTER里的`Customer[CustomerID]`——此时处于行上下文，但FILTER本身不转换上下文，所以`Customer[CustomerID]`返回的是当前行的值，而Sales[CustomerID]却要匹配这个值。听起来该工作？实际不会，因为FILTER返回的是表，CALCULATE再对这个表应用筛选，逻辑绕了两圈。

正确写法是用RELATEDTABLE或者直接利用行上下文转换：

`First Purchase = CALCULATE(MIN(Sales[Date]), Sales[CustomerID] = Customer[CustomerID])`

去掉FILTER，让CALCULATE直接接收布尔条件，行上下文自动转为筛选上下文。代码短了一半，性能好了一个数量级。

另一个高频翻车点是SUMX嵌套CALCULATE。比如算加权平均：

`Avg Price = SUMX(Sales, CALCULATE(AVERAGE(Product[Price])))`

SUMX给每一行创建行上下文，CALCULATE把它转成筛选上下文去算Product表的平均。但如果Product和Sales是多对多关系，或者Price有重复值，这个"平均"的粒度就彻底乱了。调试时建议先用SUMMARIZE把迭代过程显式打出来，确认每一层的上下文范围。

最后

那个电商团队的GMV问题，根源是他们在CALCULATE里套了三层FILTER，最内层用了一个自定义的日期逻辑，和外部的月份筛选器冲突。解决方案是把日期逻辑拆成变量，用VAR/RETURN让计算步骤显式化，而不是让DAX隐式地猜上下文。

你现在手边有没有跑起来特别慢的DAX度量值？把FILTER换成布尔条件，或者把ALL换成ALLSELECTED，再测一遍性能——这个改动在复杂模型里经常能带来10倍以上的提升。