1. 项目概述：搭建一个Power BI项目，到底难在哪儿
我见过太多人学Power BI，第一周就抱着函数列表开始背，SUM、AVERAGE、COUNTROWS背得滚瓜烂熟，结果一打开真实业务数据就傻眼。问“为什么这个同比算出来是空白”，答不上来；问“为什么总数行和表格里每一行加起来对不上”，更是挠头。问题不在于函数背得少，而在于没有理解函数在什么背景下运行。
这篇内容想解决的就是这件事。它围绕一条主线展开：先搭起一个完整的Power BI分析项目，再在项目里真正理解DAX函数。不是从头到尾讲一遍官方文档，而是把搭建过程中最关键的几个环节拆开揉碎，让你知道每个函数什么时候该用、为什么这么写、踩坑踩在哪里。适合正在学Power BI但卡在DAX上的数据分析师、运营和产品同学，也适合那些已经能画出图但总觉得自己的模型“有问题”的人。
我自己的经验是，函数理解到位之后，搭项目的速度完全不是一个量级。以前写一个带时间智能的报表要折腾一下午，现在基本上十几分钟就能把度量值全部搭完，而且出来的结果是敢直接给业务方看的。差别就在对上下文的理解，以及对函数组合方式的熟悉程度。
1.1 为什么DAX函数是“搭建”的第一道坎
Power BI的上手路径其实分三段：数据清洗、数据建模、可视化报表。很多教程把这三段拆成独立章节讲，但实际操作中它们是缠在一起的。
清洗阶段你主要在Power Query里工作，写M语言，这部分多数人学得很快，因为思维方式跟Excel比较接近。建模阶段开始接触星型模型、维度表、事实表，这里已经有人开始犯晕。真正让大多数人产生“我是不是不适合做数据分析”这种想法的，是可视化阶段开始写度量值的那一刻。
原因很简单：在Excel里，你写公式是“一个格子一个值”，眼睛能看到结果在哪。但在Power BI里，度量值是动态计算的，同一个度量值放在卡片视觉对象、放在表格、放在矩阵里，它受到的外部条件完全不同。同一个公式，旁边拖了一个筛选器，结果就变了。这种“看不见摸不着”的逻辑，就是DAX跟Excel公式最本质的区别。
打个比方：Excel的公式像是你在厨房里按菜谱一步步做菜，每步操作都看得见；DAX度量值像是你给一个机器人下了指令“把所有红色食材的卡路里总和算出来”，但机器人怎么理解“红色”，取决于你之前怎么教它识别颜色。这里的“识别颜色”，就是筛选上下文和行上下文。
所以我一直跟身边朋友说，学Power BI如果你跳过“理解函数运行机制”这一步，直接去看各种炫酷图表教程，那你永远只能抄作业，换一道题就不会写了。这也是我把文章标题定为“搭建——理解函数”的原因：搭建是过程，理解是核心。
1.2 理解函数的正确路径：从业务问题到公式
我见过很多人在学习DAX时用错方法，喜欢先从函数出发，把每个函数的语法、参数背下来，然后等着遇到能用它的场景。这种方法效率极低，因为DAX里几十个常用函数，你背完一圈，前面早就忘了。
正确的路径应该是反向的：先有一个业务问题，再想怎么用函数组合去解决。
比如业务方问“这个月跟去年同月比增长了多少”，你要先意识到这是个“时间偏移”问题，需要让日期往前拨一年，然后对比同一个度量值。这时候你自然就会去查SAMEPERIODLASTYEAR怎么用，查完之后你就记住了，而且记得特别牢。
再比如业务方问“每个月的累计销售额是多少”，这是“扩展表”问题，普通SUM做不到累计，你需要用CALCULATE配合FILTER，再加上一个比较条件。等你亲手写过一次，上下文的概念就刻在脑子里了。
这篇文章后面会带着你走一遍这样的完整流程。我们模拟一家零售企业的销售分析场景，从原始数据到最终看板，函数会一点一点变成你手里的工具，而不是躺在文档里的陌生名词。
2. 核心拆解：DAX函数的五大类与两个上下文
说DAX难，难的不是语法，而是你脑子里没有一个清晰的地图。DAX函数有几十个，如果你按“用途”而不是“名称”去归类，其实可以压缩成五大类。
第一类是聚合函数，这是最基础的，SUM、AVERAGE、MIN、MAX、COUNTROWS、DISTINCTCOUNT都算。它们负责对一组值做数学运算。第二类是筛选函数，核心代表是CALCULATE和CALCULATETABLE，它们负责改变计算时的筛选条件。第三类是逻辑控制函数，IF、SWITCH、AND、OR这类，负责做条件判断。第四类是时间智能函数，DATEADD、DATESYTD、SAMEPERIODLASTYEAR这些，负责处理跟时间周期相关的计算。第五类是上下文操作函数，VAR、RETURN、EARLIER、VALUES、SELECTEDVALUE这些，负责读取或控制当前的计算环境。
这五类里面，最关键的是第二类CALCULATE，它就像一座桥，把其他所有函数的能力串联起来。很多人学到这里进度停滞，也是因为CALCULATE里面涉及两个魔鬼概念：筛选上下文和行上下文。
2.1 筛选上下文：你给数据加了什么“条件”
筛选上下文是整个DAX体系里最重要的概念，没有之一。
你可以把它理解成“当前计算环境中所有生效的筛选条件的总和”。报表页面上的切片器、视觉对象里的行和列、报表级别的筛选器，这些都会给一个度量值“套上”筛选条件。度量值计算时，不是在整个数据表上计算，而是在“被筛选后的剩余数据”上计算。
我举个例子，你在矩阵里放了一个行字段“省份”，又放了一个度量值“总销售额”，那么当矩阵显示“广东省”那一行时，这个度量值不是在全部数据上算SUM，而是先把数据筛选到“省份等于广东省”，然后才执行SUM。这个“省份等于广东省”就是筛选上下文的一部分。
理解了这一点，很多奇奇怪怪的结果就说得通了。为什么同一个度量值放在不同视觉对象里数值不同？因为筛选上下文变了。为什么加了切片器数字就变了？因为筛选上下文增加了新条件。
但光有这个理解还不够，还有一个容易被忽略的点：计算列和度量值的筛选上下文来源不同。计算列是在模型刷新时按行计算一次，它不响应任何报表筛选；度量值是在报表交互时才计算，它每时每刻都在响应筛选。这也是为什么我强烈建议能写度量值就不要写计算列。计算列是静态的、写死的，度量值是动态的、活着的。
2.2 行上下文：当前“在哪一行”进行计算
行上下文比筛选上下文好理解一些，但更容易被误解。
当你新建计算列，写了一个公式销售额 = [数量] * [单价]，Power BI会对这个表逐行扫描，每一行都执行一遍乘法。这里的“每一行”就是行上下文。简单说，行上下文定义了“循环到了哪一行”。
问题出在度量值里能不能用人理解的行上下文。答案是不能直接使用。度量值里面没有“当前行”这个天然概念，你必须在函数内部自己创建行上下文。最典型的例子是SUMX、FILTERX这类迭代函数，它们会遍历一张表，对每一行执行内部表达式，然后汇总或筛选。被遍历的这张表就是行上下文存在的空间。
新手经常犯的错误是把SUM和SUMX混用，觉得都能算总和，差不多。但它们差多了。SUM是对一整列做标量聚合，SUMX是对表逐行迭代后再聚合。当你的计算逻辑只是简单的加总，两者结果一样；一旦需要“先算每一行的利润再汇总”，SUM就无能为力了，因为你没法在聚合过程中插入一行级的中间计算。
你只要记住：行上下文解决的是“逐行计算”的问题，筛选上下文解决的是“在当前条件下计算”的问题。一个管范围，一个管细度。
2.3 用生活类比读懂CALCULATE与上下文转换
CALCULATE为什么核心？因为它的本质是“上下文转换”。这个概念是DAX最容易卡人的地方，我换个说法讲。
想象你是体育老师，要给全班同学量身高。所谓聚合函数，就是一次量完全班、算平均身高。所谓行上下文，就是你一个个点名，逐个量。那CALCULATE是什么呢？它就像你先让全班同学换上运动服，再量身高。原本的筛选上下文是“全班同学”，CALCULATE替你加上了一个新条件：“其中穿运动服的同学”。
关键的地方来了：如果在度量值里已经有一个天然的行上下文循环，比如在SUMX的迭代里，你想在每一行计算时再套一层条件，行上下文不会自动传给CALCULATE用。CALCULATE会把当前的行上下文先忽略，只保留它自己指定的筛选条件，然后重新开始计算。这个机制叫“忽略行上下文，保留筛选上下文并叠加自己的筛选条件”。
听起来有点绕，但用大白话理解就是：CALCULATE在原本的“过滤后的数据范围”之上，再叠一层新的过滤。它不关心你当前循环到哪一行了，它只管“我要按我指定的条件筛一遍再计算”。
这样你就能理解为什么那个经典公式能算同比增长了：
销售额同比 = VAR 去年同期销售额 = CALCULATE([总销售额], SAMEPERIODLASTYEAR('日期表'[日期])) RETURN 去年同上期销售额这里CALCULATE接收了两个信息：第一个是度量值[总销售额]，第二个是时间智能函数返回的“去年同期日期集合”。整个计算的逻辑就是：把筛选上下文切换到“去年同期”，然后计算总销售额。
凡是涉及“条件变了”的计算，几乎都要经过CALCULATE。不夸张地说，你DAX水平的一半，体现在你对CALCULATE的理解上。
2.4 常用函数速查表：按使用场景索引
知道了分类，我整理了一个我自己常用的速查表。这张表是按业务场景索引的，你脑子里装着业务问题，直接去表里找函数，比按字母背函数效率高很多。
| 业务场景 | 推荐函数 | 说明 |
|---|---|---|
| 简单求和/平均/计数 | SUM、AVERAGE、COUNTROWS | 最基础聚合，直接对列操作 |
| 去重计数 | DISTINCTCOUNT | 统计不重复客户数、不重复订单数 |
| 计算每一行的中间值后汇总 | SUMX、AVERAGEX | 先逐行计算再聚合 |
| 修改筛选条件 | CALCULATE | 所有条件变更类计算的核心 |
| 按条件筛选后再计算 | CALCULATE + FILTER | 比如“只计算华东区的销售额” |
| 忽略某个筛选器 | ALL、ALLEXCEPT | 固定分母时非常常用 |
| 同比/环比/累计 | SAMEPERIODLASTYEAR、TOTALYTD、DATEADD | 时间智能主力函数 |
| 取某个列的唯一值 | VALUES、DISTINCT | 常用于矩阵内做占比 |
| 返回筛选器的当前选中值 | SELECTEDVALUE | 常用于动态标题或动态单位 |
| 多条件分支判断 | IF、SWITCH | 做维度分组、区间分段 |
你不需要一次记完。先把CALCULATE、ALL、FILTER、SUMX这几个“硬骨头”啃下来，其他的函数基本都是跟它们组合使用。我在后面实操部分会反复用到这张表里的函数，看完你就知道它们是怎么串起来的。
3. 实操纪实：从零搭建一个零售销售分析看板
前面讲的概念不少，这一节我们直接做一个项目。模拟场景是一家零售企业的销售分析，数据模型尽量简单，但业务逻辑要真实：总销售额、销售额同比、累计销售额、区域排名、订单量、利润率这几个指标都要算出来。
这个项目的目标不是为了展示花哨图表，而是用最小成本把你带一遍完整的搭建流程，让你看到函数是怎么一步步从“概念”变成“能用”的工具。
3.1 第一步：数据准备与关系建模
打开Power BI Desktop，数据源我用的是三张表：销售明细表、产品表、日期表。
销售明细表包含订单ID、订单日期、产品ID、区域、销量、销售额这些字段。产品表包含产品ID、产品名称、类别、成本。日期表则是我用DAX生成的连续日期表，从本年1月1日到12月31日。
意图很明确：销售明细表当事实表，产品表和日期表当维度表，形成典型的星型模型。为什么要独立建日期表？因为时间智能函数有一个硬性条件——必须有一张连续无空缺的日期表，并且日期列要是“日期”类型、要标记为日期表。没有这张表，SAMEPERIODLASTYEAR这类函数大概率返回空值。
日期表的生成公式很简单：
日期表 = ADDCOLUMNS ( CALENDAR (DATE(2024, 1, 1), DATE(2024, 12, 31)), "年份", YEAR([Date]), "月份", MONTH([Date]), "月份名称", FORMAT([Date], "MMM") )这里CALENDAR生成连续日期，ADDCOLUMNS在每一天后面追加年份、月份等字段。写完直接“新建表”粘贴进去就行。
接下来建关系。模型视图里把产品表的“产品ID”拖到销售明细表的“产品ID”上，日期表的“日期”拖到销售明细表的“订单日期”上。两个关系都是一对多，方向从维度表指向事实表。
这里有一个我自己多年养成的习惯：把日期表的日期列设为连续日期，并把“标记为日期表”打开。否则你后面写同比、累计时，很容易出现“计算出来全是空白”的问题。
3.2 第二步：基础度量值，先让数字“对”起来
建模完成后，第一件事不是画图，而是写基础度量值。
先写总销售额：
总销售额 = SUM('销售明细'[销售额])再写总订单量：
总订单量 = COUNTROWS('销售明细')有这两个基础值打底，然后开始写利润相关。产品表里有成本，销售明细表里有销售额，但利润是两个表字段相减，不是直接一列，所以必须用迭代函数：
总利润率 = DIVIDE( SUMX('销售明细', '销售明细'[销售额] - LOOKUPVALUE('产品表'[成本], '产品表'[产品ID], '销售明细'[产品ID])), [总销售额] )LOOKUPVALUE的作用是按照产品ID从产品表里找到对应成本。这个写法能跑通，但我得坦白说，在实际项目中我很少这么写，因为LOOKUPVALUE在这种高频计算里性能一般，更推荐的做法是提前在销售明细表里通过关系或计算列把成本带进来。
当时我实测下来，让事实表里直接冗余一个“成本”列，模型跑得更快，公式也更简洁。所以在练习阶段你可以用LOOKUPVALUE练手，但做正式项目时，尽量在建模阶段就把需要的字段都关联或合并进事实表。
写完这几个度量值，先放到一张表格视觉对象里看数字对不对。这一步叫验证基线，如果基础数字都不对，后面所有衍生指标都是建立在沙滩上的城堡。
3.3 第三步：时间智能与动态分组
基础数字对了，开始上时间智能。
销售额同比这个指标几乎是每个报表都会有的。公式长这样：
销售额同比% = VAR 本年销售额 = [总销售额] VAR 去年销售额 = CALCULATE([总销售额], SAMEPERIODLASTYEAR('日期表'[日期])) RETURN DIVIDE(本年销售额 - 去年销售额, 去年销售额)这个公式的套路我要详细说一遍，因为你以后所有的时间智能计算都是这个模板。
VAR定义变量，先把今年销售额存起来。第二个VAR里用了CALCULATE，它的第二个参数SAMEPERIODLASTYEAR会把筛选上下文里的日期整体拨回去年，于是在日历上“显示今年”的情况下，实际算的是去年同期的销售额。最后RETURN返回一个同比增长率。
这里最核心的点在于：CALCULATE内部改变了时间筛选范围，但外部筛选上下文依然是当前的年份。两个VAR一对比，同比就有了。如果你把变量换成直接嵌套的写法，很容易把上下文搞乱。一开始就养成用VAR的习惯，能少踩很多坑。
再写累计销售额：
YTD销售额 = TOTALYTD([总销售额], '日期表'[日期])TOTALYTD不需要你手动指定“从年初到今天”的筛选条件，它内部自动处理。放在表格里配合月份字段，能很自然得到截至当前月份的累计值。
还有一个很常见的需求是计算销售排名。比如看每个省份的销售额排名，用RANKX：
区域销售排名 = RANKX(ALL('销售明细'[区域]), [总销售额], , DESC, Dense)RANKX遍历所有区域，按总销售额降序排列。这里ALL的作用是取消外部筛选上下文，避免排名只在当前筛选范围内进行。
当时我在项目里跑这个公式，第一次写忘了加ALL，结果每个区域出来的排名全是1。原因就是没取消筛选上下文，RANKX每次只在“当前行的区域”里跑，自然永远是1。这就是上下文没想清楚的典型现场。
写到这里，你手里的度量值已经够搭出一个有信息量的报表了，我顺手加了一个动态标题：
标题文本 = IF( HASONEVALUE('日期表'[月份]), SELECTEDVALUE('日期表'[月份]) & "销售分析", "全年度销售分析" )IF加HASONEVALUE判断当前页是否只筛选了一个月份。有就显示具体月份，没有就显示全年度。SELECTEDVALUE从筛选上下文里提取当前被选中的值。这种细节会让报表立刻有一种“定制感”。
3.4 第四步：性能与可维护性优化
项目基本跑通以后，我不会马上收工，而是花时间整理模型和度量值。这一步很多人忽略，但它是项目能不能长期用下去的关键。
首先是命名规范。我的习惯是基础度量、计算度量和辅助度量分开，用前缀区分。比如“总销售额”这种基础值不加重命名，衍生指标统一加“计算值”、“占比”等可识别的后缀。这样做的好处是当项目里已经有几十个度量值时，你还能一眼找到自己要的。
其次是性能体检。Power BI里按快捷键Ctrl+E可以打开性能分析器，运行一次页面，看每个视觉对象的耗时。有一次我在一个矩阵里放了三层行字段和五个度量值，总耗时直接到了9秒。排查后发现问题不在视觉效果上，而在于每个度量值内部都套了FILTER，而FILTER在迭代大表时非常耗时。我把其中两个改成CALCULATE直接传递筛选条件后，耗时降到1.5秒。
这里给你一个长期经验：能用CALCULATE直接设置筛选条件，就不要用FILTER逐行迭代。CALCULATE的筛选条件是被优化的，它会直接生成查询条件；FILTER则是拿一张表逐行判断，全表扫描，性能天然吃亏。很多人把FILTER当万能药，实际上它只是某些场景下的备选方案。
最后是删除冗余列。把所有不需要的中间计算列从表里清掉。模型越大越卡，字段越少越好。
4. 常见问题与排查技巧实录
说句实在话，DAX学习中最有价值的不是那些成功的公式，而是错误信息、空白输出和性能瓶颈背后的原因。这一节把我实际工作中最常撞见的几个问题整理成速查表，再分享一些排查的工具型技巧。
4.1 常见错误对照表：报错信息一出来别慌
| 现象 | 直接原因 | 排查方向 |
|---|---|---|
| 时间智能计算返回空白 | 没有可用日期表或未标记日期表 | 检查是否新建连续日期表、是否设置为“标记为日期表” |
| 排名总是1 | RANKX未取消筛选上下文 | 检查是否遗漏ALL |
| 计算列刷新后数值不变 | 计算列本身是静态的 | 确认要不要改成度量值 |
| 函数参数类型错误 | 传了文本给聚合函数 | 检查字段类型是否为数字 |
| 总量与明细加总不一致 | 度量值受外部筛选影响 | 如果分母需要固定，用ALL或CALCULATETABLE |
| 同一度量值在不同页面数值不同 | 页面筛选器不同 | 进入“视图”检查页级筛选器 |
| 行总计行为怪异 | 总计行也处于当前上下文 | 需要理解总计不是所有行相加 |
我印象最深的是“排名总是1”这个坑。当时A同学把销售表按区域排了个名，放出来每个区域排名都是1，他以为是自己RANKX参数写错了，折腾了半天。实际上就是RANKX的第二个参数在遍历过程中受到了当前行的上下文影响，每次只在一个区域里排名。加上ALL之后瞬间正常。
这个案例也说明，排查DAX问题的时候，第一反应不要是怀疑函数语法，而是先问一句：当前上下文是什么？它在遍历什么范围？
4.2 性能慢，九成是模型和上下文的问题
做Power BI项目时间长了，你会发现性能问题其实比错误问题更常见。数据量稍微一上来，报表打开就转圈，很多人第一反应是“数据太多了”，跑去问要不要换数据库。但多数情况下，问题出在DAX写法上。
写一个大家最容易踩的坑：直接在筛选函数里嵌套一个“应该被提前过滤”的计算列。比如你为了算利润率，在销售明细表里新建了一列“利润额”，然后很多度量值在这列上叠加了多层CALCULATE。这个列本身没问题，但如果某些度量值里又用了FILTER去遍历明细表，那性能会断崖式下降。
我的排查办法很简单：用性能分析器，逐步刷新一个视觉对象，看耗时。如果发现某个视觉对象特别慢，就把它上面的度量值一个一个拆下来，放到卡片视觉对象里单独计时。这样能快速定位是哪条公式拖了后腿。
平时写公式的时候，还要养成一个习惯：尽量把重复使用的表达式定义成变量。比如：
销售额增长 = VAR 销售额本年 = SUM('销售明细'[销售额]) VAR 销售额去年 = CALCULATE(SUM('销售明细'[销售额]), SAMEPERIODLASTYEAR('日期表'[日期])) RETURN 销售额本年 - 销售额去年这样不仅可读性好，而且Power BI引擎只会计算一次变量，不会一遍一遍重复扫描表。对于大数据量场景，这个习惯能省不少时间。
4.3 避坑心得：这些是我踩过之后才记住的经验
第一，不要一开始就想把整个公司的模型一次性搭完。先做最小的闭环：两张表、三个度量值、四个视觉对象。把流程跑通之后，再逐步加维度、加指标。很多人上来就铺一个几十张表的复杂模型，结果关系都乱了，最后连自己写过的公式都读不懂。
第二，度量值的命名不要用“占比占比”这种名字，也别起那种看不懂的缩写。我自己吃过大亏，项目做大了以后，几十个度量值堆在一起，没有命名规范的话，找个指标要翻半天。现在我常用的规则是三个层次：基础计算、业务比率、汇总汇总。分类清楚比什么高级技巧都重要。
第三，写完每个度量值，马上放到可见的表格视觉对象里验证，不要一次性写五个再集中验证。因为你一次性写五个，一旦中间一个逻辑错了，你要排查的范围就扩大了。写一个验一个，这个习惯会帮你节省大量时间。
第四，如果某个计算结果跟Excel核对不上，先检查有没有“重复值”或者“空白值”混在数据里。很多时候不是DAX写错了，而是原始数据里同一批订单出现了两次，或者日期字段存在空值。函数本身没错，数据先脏了。做项目前花时间把数据质量理一遍，远比在公式里绕来绕去更高效。
结尾：最后给你一套DAX学习的最小实践路径
文章写到这儿，该讲的核心内容基本都覆盖了。很多人在读完一篇干货之后，容易产生一种“哦我懂了”的错觉，但一打开软件又不知道先干嘛。所以最后一节，我不做总结，就分享一套我自己送给朋友的学习顺序。
第一次接触Power BI，先不要去看视频课程，也不要急着买在线教程。直接用自带的数据集，跟着这篇文章的步骤走一遍。第一天只需要完成三件事：建日期表、建关系和写一个总销售额。第二天再尝试加一个CALCULATE、一个时间智能函数。第三天试着给业务场景加一个分组逻辑。三天下来，你对函数的理解会比看半个月书来得更牢。
之后的进阶方向，我认为是两条线：一条往模型深入，去理解星型模型、粒度、关系方向这些数据建模概念；另一条往上下文深入，去啃CALCULATE、上下文转换、扩展表这些DAX核心机制。这两条线互相补充，真正掌握之后，你再看任何复杂报表，脑子里都会自动浮现出它的数据流向和筛选过程。
我在实际工作中最大的感受是：Power BI只是一个工具，真正拉开差距的，是你拿到一个模糊的业务问题时，能不能快速把它拆解成清晰的筛选条件、聚合逻辑和关系结构。函数不过是这些逻辑的最终表达形式。你把思路想清楚了，DAX自然就通了。
