Power BI DAX统计上次不良后良好工作日数的度量值失效原因

核心错误逻辑 #

第一个度量值失效，本质是踩了DAX最常见的上下文转换坑，执行逻辑拆解如下：

• 外层FILTER(Table, ...)会逐行遍历Table的所有记录，遍历到每一行时都会生成对应行的行上下文。
• 内层嵌套的CALCULATE(MAX(Table[Date]), Table[Result] = "bad")有个默认规则：会自动把外层FILTER当前遍历行的行上下文转换成筛选上下文。说白了，内层算MAX日期的时候，初始查找范围已经被锁死在「当前正在遍历的这一行」里了。
• 这时候再加Table[Result] = "bad"的筛选条件，相当于要求找的记录同时满足「就是当前遍历的这行」和「Result值为bad」。当FILTER遍历到Result是Good的行时，这两个条件完全矛盾，内层CALCULATE找不到匹配记录，永远返回空值BLANK。
• 最后判断条件Table[Date] > BLANK()对所有有效日期都成立，等于FILTER里写的日期筛选完全没起作用，只剩外层Table[Result] = "Good"的筛选生效，自然就返回了全表所有Good的记录数，和预期不符。

另外两个度量值正常运行的原因 #

两个能用的版本，本质都是显式指定了内层计算的范围，躲开了内层CALCULATE乱继承外层迭代上下文的问题：

• 第二个度量值在内层CALCULATE里加了Table作为筛选参数，作用就是清掉当前遍历行带来的窄范围筛选，把计算范围恢复到整张表，之后再加Table[Result] = "bad"筛选，就能正确算出全表最近一次bad对应的日期。
• 第三个度量值直接显式写了FILTER(Table, Table[Result] = "bad")作为内层CALCULATE的筛选参数，明明白白告诉DAX：算MAX日期的时候，就找全表里Result为bad的记录，别拿外层遍历的行上下文来干扰计算，所以也能返回正确结果。

写DAX碰到FILTER里套CALCULATE的场景一定要多留心：内层计算默认会继承外层迭代的行上下文转成筛选条件，很容易把计算范围收窄到单行导致结果错误，必要时可以用ALL类函数、或者显式指定筛选表的方式固定计算边界。

内容的提问来源于stack exchange，提问作者Haico