获课：aixuetang.xyz/23268/

在 Power BI 的数据分析与建模体系中，DAX（数据分析表达式）是驱动动态计算的核心引擎，而理解“上下文（Context）”则是掌握 DAX 的第一性原理。对于许多从 Excel 转型而来的分析师而言，行上下文与筛选上下文的概念往往是最难跨越的认知鸿沟。这两种上下文并非孤立存在，而是共同决定了公式的评估环境，厘清它们的运行机制与交互逻辑，是实现复杂业务指标精准计算的关键。

行上下文（Row Context）本质上代表了 DAX 评估环境中的“当前行”。当系统逐行处理数据时，行上下文便自动生效。它主要存在于计算列以及诸如 SUMX、FILTER 等迭代函数中。在这种模式下，引擎能够感知并提取当前行的所有列值，从而进行诸如单价乘以数量等逐行运算。然而，新手最容易陷入的认知误区在于：行上下文本身并不具备筛选数据的能力。它仅仅是一个“指针”，告诉你当前正在处理哪一行，但不会自动过滤表中的其他数据。如果需要在迭代过程中基于当前行的值去匹配或聚合其他数据，就必须借助 EARLIER 或 EARLIEST 等函数来跨越嵌套循环，准确捕获外层循环的行上下文状态，否则极易导致计算结果发生混淆或返回全表的无效汇总。

相比之下，筛选上下文（Filter Context）则决定了参与计算的“数据范围”。它是一种更为宏观和动态的环境，由报表层面的视觉对象、切片器、页面筛选器，以及 DAX 内部的 CALCULATE、ALL 等修改上下文的函数共同构建。筛选上下文的核心价值在于其动态性：同一个度量值被放置在不同的矩阵单元格中时，由于所在位置的行列标题不同，其背后的筛选上下文也会随之改变，从而计算出截然不同的结果。此外，筛选上下文还具备沿模型关系向下传播的特性，能够自动过滤相关表中的数据子集，这是实现多维度交叉分析的基础。

在实际的高阶建模中，真正的技术难点往往出现在这两种上下文的交汇与转换处。最典型的场景便是“上下文转换（Context Transition）”。当一个包含行上下文的迭代器内部嵌套了 CALCULATE 函数时，CALCULATE 会强制将当前的行上下文转换为等效的筛选上下文，并将其应用到内部表达式的计算中。这一机制虽然强大，允许开发者在逐行遍历时执行带有筛选条件的聚合操作，但也极易引发意料之外的性能瓶颈或逻辑错误。例如，如果在大型事实表的迭代中频繁触发上下文转换，可能会导致引擎生成庞大的临时筛选器集合，进而严重拖慢刷新速度。

因此，要彻底攻克 Power BI 的上下文难点，开发者必须摒弃 Excel 时代基于单元格引用的静态思维，建立起基于集合操作与关系模型的动态评估视角。在编写公式前，应当先在脑海中清晰地勾勒出当前所处的行环境，以及外部施加的筛选条件，明确 CALCULATE 等函数将如何重塑这些条件。只有深刻理解行上下文的微观遍历机制与筛选上下文的宏观约束能力，并熟练掌握两者之间的转换边界，才能真正驾驭 DAX 的强大算力，构建出既准确又高效的企业级数据模型。