Power BI多文件合并实战：文件夹读取与自动汇总全指南

做数据分析这些年，我处理过不少“把几十张表合并成一张表”的需求。销售日报、门店周报、渠道回款明细、临床数据导出……凡是业务系统不支持直接汇总的文件，最后都会堆到一个文件夹里等着人来合并。这个活儿烦人，但几乎每个用PowerBI的团队都会遇到。这篇文章就把我实践下来最靠谱的多文件读取合并方法完整拆开讲：什么时候用文件夹方式、具体怎么操作、常见坑怎么避、以后怎么扩展。适合正在用Power BI做数据分析、每天被Excel合并折磨的同事参考。

先说一个我踩过的教训：早期我也是老老实实把每个Excel导进Power BI，再逐个用追加查询拼在一起。一个月度销售看板要连十几个报表，每来一个新月份，就要手动再导一次，烦到怀疑人生。后来我才彻底换成文件夹读取方案，Power BI自己扫描目录、自动套用合并逻辑，新增文件只要丢进文件夹、点一下刷新，数据就全部到位。这篇博文会把整套思路和代码一并交代清楚，你照着做，基本上一下午就能把月度报表流搭起来。

1. 先搞清楚：多文件合并到底在解决什么场景

1.1 我遇到过的高频合并场景

多文件读取合并不是技术炫技，它背后是一批非常现实的数据需求。我印象最深的几类：

• 销售团队每个门店每天发一张Excel日报，总部要按周、按月汇总所有门店的销售和客流数据。
• 财务每月从ERP导出多张科目余额表、费用明细表，做预算分析前需要把所有表合并成一张大表。
• 运营手里有几十个CSV格式的活动投放数据，来自不同渠道，字段顺序还不太一样。
• 临床研究每周从系统里导出一批受试者随访数据，文件名带日期，需要合并后做疗效和安全性分析。
• 制造业车间每台设备生成一个数据文件，采集频率高，文件数量动辄上百。

这些场景的共同特征很明显：文件数量多、格式相似、命名有序、更新频繁。你不可能每周打开一百个文件手动复制粘贴，也不可能要求业务同事先把所有表整理成一张再发给你。最合理的做法，是让工具自动扫描文件夹、按统一规则读取并堆叠数据。这恰恰就是Power BI里文件夹连接器最擅长的活。

1.2 为什么我推荐用Power BI而不是Python或Excel

先说Excel，它本身也有Power Query，同样能读文件夹。但对这种不断更新、需要分享、需要做成看板的场景，Excel的硬伤在于文件容量和协作方式。几十兆的数据塞进Excel，刷新一次卡半天，而且你没法给团队做一个自动刷新的大屏看板。Python当然灵活，pandas一读一拼就完了，可它对业务同事不友好，你走了以后这个流程就没人能维护。Power BI的优势在于：自带Power Query做数据整理，自带数据模型做关联和度量值，自带可视化看板，还能在服务端制定刷新计划。对中等体量的业务数据来说，它是性价比最高的选择。

当然，如果你的数据量到了几千万行，或者要做复杂的文本抽取、网络爬虫、模型训练，那Power BI不是干这个的，直接用Python更合适。但如果只是“每周把一堆Excel合并成表”，Power BI的文件夹方案就是最优解。

2. 弄明白Power Query自动合并的原理，后面才不会慌

2.1 文件夹连接器：把“读文件”变成“读目录”

很多人第一次用文件夹连接器时，会误以为Power Query是把文件一个个读进来再合并。实际上不是。当你选择“获取数据→文件夹”时，Power Query只做了一件事：扫描整个目录，生成一张包含文件名、扩展名、文件路径、修改时间、内容等元数据的表。它并没有真正打开每个Excel文件。这一步非常快，所以你第一眼看到的是文件清单，而不是文件里的数据。

这个设计很聪明。Power Query把“读文件”这件事拆成了两层：先“看目录”，再“读内容”。看目录是轻操作，读内容是重操作。你可以在看目录这一层做筛选，比如只保留.xlsx文件、去除隐藏的临时文件、只保留某个月份的文件，然后再触发真正的读取和解析。理解这一点，对后面优化性能特别重要。

2.2 “示例文件当模板”才是合并的底层逻辑

合并文件时，Power Query会做一件很多人不知道的事：它默认取文件夹里的第一个文件作为模板，解析出这个文件的结构，然后把这个解析过程保存成一个参数、一个函数。后面再处理其他文件时，它把每个文件依次塞进这个函数，套用统一的清洗逻辑，最后把结果表堆叠起来。

这个逻辑听起来简单，但藏着两个重要推论：第一，你的第一个文件必须结构标准，如果第一个文件本身表头混乱或者列缺失，整个合并就会错。第二，合并是按列名或列位置匹配的，其他文件的列名如果跟模板对不上，就会出现错位、多列、Null值。很多人合并完发现数据乱了，第一反应是“Power BI有毛病”，其实问题出在文件本身不统一，而Power Query按模板处理了所有文件。

2.3 自动生成的M代码到底做了什么

用文件夹方式合并后，Power Query会自动生成几个查询，通常是一个“示例文件”参数和一个“转换示例文件”函数。你要是打开高级编辑器，会看到类似这样的M代码：

let 源 = Folder.Files("D:\经营数据\销售日报"), 筛选的扩展名 = Table.SelectRows(源, each [Extension] = ".xlsx"), 删除其他列 = Table.SelectColumns(筛选的扩展名, {"Name", "Content"}), 调用转换函数 = Table.TransformColumns(删除其他列, {{"Content", 转换示例文件, {"Name"}}}), 展开的Content = Table.ExpandTableColumn(调用转换函数, "Content", {"日期", "门店", "销售额"}, {"日期", "门店", "销售额"}) in 展开的Content

这段代码的含义是：先读目录，再筛选出Excel文件，然后只保留文件名和二进制内容两列，接着用“转换示例文件”这个函数去处理每个文件的Content，最后把处理出来的“日期”“门店”“销售额”列展开。理解了这个结构，你就知道哪些环节可以动手脚了：想过滤文件就在“筛选”步骤改，想改清洗逻辑就进“转换示例文件”函数里改。

3. 实操：从文件夹读取到一张清爽的数据表

3.1 动手前先把文件夹整理好，能少一半坑

我不止一次见过有人把合并做失败，最后发现是源头文件太乱，跟Power BI没有半点关系。所以在开始任何操作之前，先做三件事：

第一，把要合并的文件放进同一个文件夹，不要一会儿在桌面、一会儿在下载目录。子文件夹能不加就不加，加了会增加处理复杂度。第二，统一文件格式。要么全是.xlsx，要么全是.csv，千万不要混着来。混合格式会让模板和函数配置变得复杂，默认的合并流程没法同时处理两种类型。第三，统一列名和Sheet名。如果你用的是Excel文件，多个Sheet时Power Query一般会按你选择的Sheet名去匹配，如果某个文件的Sheet名不一样，就会报错或者读不到数据。

还有一个我自己的习惯：在文件夹里放一个“标准模板文件”，把列名、示例格式都做好，然后把它放在文件夹第一位。因为Power Query默认拿第一个文件当模板，这样就能保证模板永远是正确的。很多踩过坑的人后来都学乖了：正规业务表前面永远放一个“00_模板.xlsx”，既给文件排序，又给合并逻辑兜底。

3.2 连接文件夹并完成第一次合并

具体操作步骤不复杂，但有些细节新手容易忽略。

在Power BI Desktop里依次点击“主页→获取数据→文件夹”，会弹出目录浏览窗口，填好路径后点“确定”。此时Power BI会显示文件夹里的文件清单，注意观察左下角，有两个按钮：“合并并转换数据”和“合并和加载”。这里我强烈建议选“合并并转换数据”，因为合并后大概率还有很多清理工作要做，直接加载进模型后还得回到查询编辑器改，多绕一圈。

点完按钮后，Power Query会打开“组合文件”对话框，让你选择示例文件。默认选中的是文件夹里的第一个文件，你确认一下模板文件在第一位就行。下面还有一个参数选项，保持默认即可。点确定后，Power Query会生成两个查询，一个叫“示例文件”参数，一个叫“转换示例文件”函数。后面那个函数是可以进去改清洗逻辑的，别删。

这时你会在查询列表里看到主查询，它的“Content”列已经被转换成一张张表。点一下“展开”按钮，选择你需要的列，把“使用原始列名作为前缀”取消勾选，就能把数据全部展开成一张宽表。到这里，第一个合并流程就走通了。

3.3 数据清洗要点（列名、日期、类型、隐藏行）

展开之后别急着加载，一定要在Power Query里把数据洗干净。我按踩坑频率排序，列几个必做项：

日期列是最容易出问题的。Excel里的日期本质上是数字序列，如果合并时没被正确识别，就会出现一列类似“45678”的数值。遇到这种情况，选中该列，把数据类型改成“日期”，Power Query通常能直接转过来。如果还不行，就构造一个新列，用Date.From(Number.From([日期列]))转换。

金额和数量列，要注意类型是否被识别成了“文本”。如果合并时某些文件里的金额带了千分符、货币符号，Power Query就会把它们当文本读取。解决办法是统一格式后在转换函数里强制改成“小数”。另外，有些Excel模板里有多余的空行、空列，合并后会出现大量Null值，用“删除空白行”或者按关键列做非空筛选就能处理掉。

还有一个非常推荐的步骤：在展开后的表里保留“Name”列，并把它重命名为“来源文件”。这样以后任何一行数据有问题，你都能追溯到是哪个文件带来的，排查效率高很多。

3.4 把路径参数化，支持后续刷新扩展

合并不难，难在维护。如果哪一天文件夹被移动了、或者你想在同一个工作簿里做多个项目的合并，硬编码在M代码里的路径就会变成麻烦。Power Query提供了参数机制解决这个问题。

在“主页→管理参数→新建参数”里创建一个文本参数，比如叫“数据目录”，默认值填文件夹路径。然后在主查询的“源”步骤里，打开高级编辑器，把Folder.Files("D:\经营数据\销售日报")中的路径替换成Folder.Files(数据目录)。以后要改路径，只需要改参数，不用再进M代码。

这个操作在本地看好像无所谓，但如果你把报表发布到Power BI服务，配置数据网关和数据源刷新时，参数化管理会让你省掉很多重复操作。我在实际项目里，甚至把“文件后缀名”也做成了参数，方便在不同环境里切换Excel和CSV。

3.5 一份可以直接套用的完整M代码

如果你的文件结构比较标准，不想通过界面点来点去，可以直接把下面这段M代码粘到高级编辑器里，改一下路径和字段名就能用：

let 数据目录 = "D:\经营数据\销售日报", 源 = Folder.Files(数据目录), 移除临时文件 = Table.SelectRows(源, each not Text.StartsWith([Name], "~$")), 筛选Excel = Table.SelectRows(移除临时文件, each [Extension] = ".xlsx"), 仅保留必要列 = Table.SelectColumns(筛选Excel, {"Name", "Content"}), 调用转换函数 = Table.TransformColumns(仅保留必要列, {{"Content", 转换示例文件, {"Name"}}}), 展开数据表 = Table.ExpandTableColumn(调用转换函数, "Content", {"日期", "门店", "销售额"}, {"日期", "门店", "销售额"}) in 展开数据表

注意，代码里的转换示例文件是Power Query自动生成的函数名，它的实际名称可能带前缀或后缀，你以左侧查询列表里实际的函数名为准。另外，Table.ExpandTableColumn里的字段列表必须和转换函数输出的列名一致，否则展开会报错。

4. 实战中遇到的高频问题排查实录

4.1 问题速查表

这张表基本覆盖了我会诊时遇到的大部分情况。下面挑几个展开讲。

4.2 逐个拆解：列名错位、日期序列号、CSV乱码、临时文件干扰

列名错位是我见过最多的坑。业务同事可能会在某个文件里多加一列备注，或者在另一个文件里改了列名。Power Query合并时以模板文件的列名为准，其他文件多出的列它不认识，就会以“新列”的形式出现在最右边；而某些列名不一致的字段，就可能被当成Null。遇到这种情况，要么你强势要求业务部门按模板填，要么在“转换示例文件”函数里做更严格的处理：读取文件后，只保留目标列名集合，用Table.SelectColumns配合固定列清单清洗。

日期序列号的问题，根源在于Excel内部日期存储机制。它是把日期存成数字，再靠显示格式伪装成日期。当Power Query无法推断该列类型时，就会露出数字原形。你可以在“转换示例文件”函数里提前转换：先看Excel.Workbook返回的列类型，再对日期列执行Table.TransformColumnTypes，把它显式改成“类型日期”。这样合并出来的表就不会再出现数字日期。

CSV乱码，通常是因为文件的编码和Power BI本地区域不一致。国内很多业务系统导出的CSV是ANSI或GBK编码，而Power BI默认按Unicode读取，结果中文全变乱码。解决办法是进入“转换示例文件”函数，在Csv.Document步骤的“更改源”设置里，把“文件原始格式”改成“65001: UTF-8”或“936: ANSI/OEM - 简体中文 GBK”。改完以后必须检查转换示例文件函数，而不是在主查询上改，因为所有文件都走这个函数。

临时文件干扰，是Windows环境下非常隐蔽的问题。如果你打开过某个Excel文件，系统会在同一个目录生成一个以“~$”开头的隐藏临时文件，正常“获取数据”时不会显示，但文件夹连接器能扫到。如果不做筛选，合并时可能读到损坏的临时文件，导致某一行全是错误。在第一步就要用代码过滤掉：each not Text.StartsWith([Name], "~$")，顺手把隐藏属性也排除掉更稳妥。

4.3 几十个文件合并慢，怎么优化

合并时间太长，通常表现在两个阶段：展开Content列时卡顿，以及加载到数据模型时卡顿。我试过几十个Excel文件，每个文件几百行数据，合并起来其实很快。但如果每个文件有几十个Sheet、几十列，展开速度就会显著下降。

第一原则是“能少读就少读”。文件夹连接器扫描后，先筛选出你真正需要处理的文件，比如只保留特定月份开头的文件名，再进入转换函数。第二原则是“先瘦身再展开”。在“转换示例文件”函数里，把每个文件读进来后，先删除不需要的列，再展开到主查询。因为主查询的展开是把每个文件的完整表格一次性拉出来，瘦身之后的数据量能小很多。第三原则是慎重使用CSV。CSV的解析比Excel快很多，不需要启动OLE/COM组件，如果你是从数据库导出的话，尽量让业务系统直接导出CSV，合并速度能提升好几倍。

还有一个容易被忽略的点：不要保留“启用加载”的中间查询。Power Query里那些参数和函数不会加载到数据模型，但如果你手工新建了其他辅助表，记得右键设置为“仅启用刷新”，否则报表模型里会多出一堆看不见的表，拖累加载速度。

4.4 刷新失败与维护问题

报表发布到Power BI服务后，刷新失败是第二个高频问题。服务端刷新时，它需要找到你的本地文件夹。如果你没有配置数据网关，Power BI服务不可能访问你的本地磁盘。即使配置了网关，如果文件夹路径在参数里被改了，或者在服务端数据源配置里没有更新，刷新一样会挂。

我的经验是，所有文件夹路径都走参数，然后在发布后打开“设置→数据源凭据”，重新输入网关上的路径。本地文件夹一般选“Windows”认证，指向网关机器上可访问的目录。记住一个原则：Power BI服务上的文件夹路径是相对于网关机器的，不是相对于你的笔记本的。这个认知能帮你省掉大量来回试错的时间。

5. 一些可以直接抄的进阶技巧与经验收尾

5.1 自定义函数处理“非标准”文件

文件夹里偶尔混进来几个格式不一样的Excel，比如别人的表是交叉表结构，行里既有科目又有月份，不是标准的一维表。这种情况下，默认合并流程会直接报错或读出一堆无意义的行。

我的做法是写一个容错函数，让Power Query先尝试按标准逻辑解析，失败的话再走另一套解析逻辑。M语言里的try ... otherwise可以做到这一点。举个例子，你可以在“转换示例文件”函数里写：

let 尝试解析 = try 标准解析步骤(Content) otherwise null, 结果 = if 尝试解析 = null then 备用解析步骤(Content) else 尝试解析 in 结果

当然，这种处理方式比默认合复杂一点，需要你对M函数有一定了解。如果只是偶尔一两个文件，直接把那个文件在Excel里转成标准格式再放进文件夹，是性价比最高的办法。如果经常有特殊格式混进来，再花半小时写容错函数。

5.2 我的几个实战心得

心得一：不要相信人会按规范命名。就算你写清楚了文件命名规则，也一定有人不照做。所以在合并逻辑里尽量用“扩展名+模板结构”去约束，而不要依赖文件名排序。文件名只是辅助，不是标准。

心得二：做完合并后，立刻把“示例文件”参数和“转换示例文件”函数重命名成有意义的名字，比如“销售日报模板”和“转换销售日报”。默认生成的名字过两周你自己都想不起来是什么，更别提接手你报表的同事。

心得三：强烈建议保留“来源文件”列。只要数据出了问题，这一列能让你马上去翻原始文件，而不是在合并结果里瞎猜。这是所有数据链路里最便宜的一条后路。

心得四：文件夹方案最怕“文件结构不统一”，所以一定要维护一个标准模板文件放在文件夹第一位。我甚至会在模板文件第一个Sheet里写一段说明文字，告诉业务同事“这是标准模板，请复制这个文件修改，不要自己新建格式”。以我的经验，这条说明能减少一半的报错。

最后再分享一个小技巧：如果多个Excel文件有多个Sheet，而你每个Sheet都要合并，不要把这件事交给界面默认操作，那只会让你抓狂。直接在转换函数里用Excel.Workbook(Content, null, true)读取所有Sheet，再展开Data列做纵向堆叠。这一招能处理大量“一个文件等于一个数据集”的场景，唯一的要求是每个Sheet的表头结构一致。说真的，多文件读取合并这个能力，只要用顺手了，你会发现自己处理报表的方式完全不一样——从“一个个打开文件拼数据”变成了“搭一条自动流水线”。把文件夹权限管好，把模板文件管好，剩下的交给Power Query去跑就行。