在《圣经2》中，关于上下文理解这一块，白茶看到两个有意思的小测试，决定分享给各位小伙伴。
这是一份销售数据，将其导入到PowerBI中。
结果如图。
现在开始进行问题描述。
问题一：
为数据模型添加计算列，输入如下代码公式，结果是什么？
销售额 =
SUM ( '示例'[销售价] )A、[销售额]所在的每一行的数字都不一样。
B、[销售额]所在的每一行数字都一样。
C、公式报错；无法显示，因为计算列不允许使用SUM函数。
小伙伴们，请根据上面的示例文件，思考计算列的结果。
开始思考！
1
2
3
4
5
6
7
…
小伙伴们，有结果了么？
没有的话可以在这里停留一下。
…
问题二：
在度量值界面编写下面代码，不嵌套任何聚合函数，结果是什么？
利润率 =
( '示例[销售价]-'示例'[进价] ) / '示例'[进价]A、公式输入没问题，但是显示没结果。
B、错误，系统提示不行，有红色波浪线。
C、公式没问题，但是显示结果不对。
开始思考！
1
2
3
4
5
6
7
看到这里，咱来看看正确答案。
问题一的答案：
B、每一行的数字都显示的一样。
解析：
因为SUM本身是一个聚合类的函数，它本身的聚合只是针对表中的某一列，唯一影响它计算结果的是筛选上下文。
在表中添加新列输入SUM函数，这个时候它的计算环境是行上下文。
环境是行上下文，执行要求是筛选上下文，这二者相碰撞结果是什么？
就是筛选上下文为空！就像在表格中我们不选择某一对象，那么默认无筛选，就会显示所有结果的汇总一样，所以这里呈现的结果是每一行都相同。
与SUM函数类似的还有MIN、MAX等基本聚合类函数。
问题二的答案：
B、错误，系统提示不行，有红色波浪线。
解析：
度量值计算的前提是什么？上下文！
还记得之前白茶提过的概念么？
激发迭代→逐行取值→计算。
度量值不像计算列一样，计算列会依据左边的列，逐行的匹配值，进行相关的结果计算，说白了就是自带行上下文。在题二的度量值中，每一行都有不同的数字，没有对它进行上下文设定，度量值就懵了！
它的内心想法就是：
卧槽！
80要减去哪个16？
这么多16！
16前面这么多值，谁是他对象！？
这不是刁难我度量值一样么！
明白了吧，就好比有人告诉你，你的相亲对象是大街上的一个女的！
这咋找？范围太广了啊！完全没思路啊！
通过两个小例子，希望小伙伴们能够明白行上下文与筛选上下文的区别。如果白茶表述的不当，也请各位小伙伴多多谅解。
（白茶：T^T瞎唠叨一通，各位大佬别较真）
这里是白茶，一个PowerBI的初学者。
ID:Storysming