企业官网建设流程全解析

简介：这份《Power Query入门手册》是一份面向Excel报表自动化初学者的PDF指南，系统讲解Power Query（PQ）的数据预处理方法，涵盖从文本/CSV/Excel等数据源的获取、清洗、转换到合并查询的全流程，帮助用户摆脱手工复制粘贴，高效完成数据导入与整理。手册共1个PDF文件，约3.13MB，内容组织清晰，从入门案例到数据清洗十招循序渐进，覆盖文件导入、M函数、添加自定义列与条件列、逆透视、分组依据、追加查询、模糊查询等操作，并配有具体应用步骤说明。已有4577人学习查看，适合希望提升Excel数据分析效率、快速上手PQ的办公人群。通过这本手册，读者可掌握数据导入、清洗、转换和组合的核心技能，建立系统的数据预处理工作流。

1. Power Query 入门手册：为什么说它比函数公式更值得你花时间

先抛一个反直觉的结论：Power Query 入门手册里最该先理解的，不是某个具体功能按钮，而是“你在界面里的每一次操作，都会被自动记录成一段可回放的 M 公式”这件事。很多从业者以为 Power Query 只是 Excel 里多了一个叫“获取数据”的菜单，实际上它是一套独立的数据整理引擎，专门把粘贴、复制、查找替换这类重复劳动，变成一次建立、之后每次一键刷新就能重跑的流程。我见过太多人还在用 VLOOKUP 串表、用复制粘贴合并十几个报表，其实这些活交给 Power Query，半小时能建成一个能用一年的清洗模板。

这份手册适合谁？如果你每天要处理多个工作表、格式不统一的 CSV、甚至要连数据库做报表，但每次都被数据清洗拖住，它就是你的后悔药。新手可以按章节从零搭一条完整的数据加工流水线；已经用过一段时间的人，也能在“查询折叠”“参考查询”“错误处理”这些细节里找到自己之前没完全捋清的环节。整本手册只讲一个核心：怎么在 Power Query 里把脏数据变成结构稳定、可以反复刷新的数据源，而不是去背那些永远记不住的函数。

2. 理解 Power Query 的底层机制：查询列表、步骤和 M 公式

2.1 查询列表是什么：一个查询就是一条可回放的数据加工线

打开 Excel，切到“数据”选项卡，点“获取数据”→“启动 Power Query 编辑器”，你会看到左侧有一块“查询”窗格，中间是数据预览区，右侧是“查询设置”。这套布局和 Excel 主界面完全不一样，初次接触会觉得陌生，但它对应的其实是数据加工的思路：左侧管“有哪些加工任务”，中间管“当前数据长什么样”，右侧管“这个任务已经做了哪些步骤”。

一个查询就是一条完整的数据加工线。它可以从一张 Excel 表开始，也可以从一个文件夹下的几百个文件开始，甚至可以从数据库里的某个视图开始。你后续做的每一步——删列、改类型、筛选、分组、合并——都会依次记录在“已应用步骤”里。这个步骤列表不是临时日志，它是这条加工线的施工图纸，记录了你对数据做了哪些操作、按什么顺序做。

值得注意的一点是，查询列表本身是可以重命名、复制、删除的。我一般会建议团队里每个人给查询起“看得懂的名字”，比如“订单明细_清洗后”，而不是默认的“查询1”。因为当查询数量超过十个之后，靠默认名称你根本分不清哪个是哪个。复制查询时也要小心，右键菜单里有两个选项：一个是“复制”，一个是“创建参考”。复制会把当前所有步骤原样克隆一份，之后互不影响；创建参考则是新建一个查询，它的源是这个查询的结果，源一变，它也跟着变。这两者的区别如果没搞清，后面维护时会踩大坑，我自己的血泪经验是：做下游分析报表时优先用“创建参考”，而不是复制，因为复制会留下两套需要同时维护的清洗步骤。

2.2 已应用步骤的本质：每一步都吃上一步的“表”

“已应用步骤”里每一行，比如“删除的列”“筛选的行”“更改的类型”，看起来像操作记录，但它的本质是数据转换链上的一环。上一步输出的表，会作为这一步的输入；这一步输出的新表，再传给下一步。整个过程中间看不到临时文件，数据始终在内存里流动。

理解了这个，很多让新手迷惑的现象就能解释了。比如你在第 3 步删掉了“备注”列，第 5 步又有一个基于“备注”列的筛选，当你回头删除“删除的列”这个步骤时，第 5 步会立刻报错。原因很简单：第 5 步想要的字段在链条上游已经不存在了。Power Query 非常诚实，它不会智能地猜测你想干什么，只会按步骤顺序严格执行。

还有一个新手容易忽略的地方：步骤的顺序直接影响性能。同样是先筛选还是先改类型，看起来结果一样，但过程差异很大。比如一张 100 万行的表，你先在“更改的类型”里把日期列改为日期格式，再筛选某个月份的数据，Power Query 会先把 100 万行全部做了类型转换，再筛掉大部分行；但如果先筛日期范围再改类型，它只用处理筛剩下的几万行。这个习惯越早养成越好，它比你后面学的任何优化技巧都管用。

另外，步骤名称是可以双击修改的。改成一个能表达意图的名字，比如把“筛选的行”改成“筛选金额大于1000的行”，对整个查询的可读性提升很大。尤其是交接工作时，别人打开你的查询，能直接看懂每一步在干什么。

2.3 看懂 M 公式：刷新一次就是完整的重放

当你打开“视图”选项卡，勾选“公式栏”，就能在每一步的顶部看到对应的 M 公式。Power Query 的底层语言叫 M，界面里的每次点击都会生成一段 M 表达式。你不用一开始就学写 M，但必须能看懂它，因为很多复杂的操作是在“高级编辑器”里手动改公式来完成的。

看一个最简单也最常见的例子，从 Excel 工作簿读取一个名为“订单”的工作表，然后改类型、筛金额大于 100 的行：

let 源 = Excel.Workbook(File.Contents("C:\data\orders.xlsx"), null, true), 订单表 = 源{[Item="订单", Kind="Table"]}[Data], 更改的类型 = Table.TransformColumnTypes(订单表, {{"金额", type number}, {"日期", type date}}), 筛选的行 = Table.SelectRows(更改的类型, each [金额] > 100) in 筛选的行

逻辑并不复杂：let开头，in结尾，中间每个等号左边是一个步骤名，等号右边是这个步骤的表达式。每一步引用上一步的名字作为输入，最后in后面的那个步骤名就是整个查询的输出。你看到的“已应用步骤”列表，本质上就是这个 M 表达式的可视化外壳。

注意几个关键参数：Excel.Workbook的第二个参数null表示不把首行自动识别为标题，第三个参数true表示使用表类型；Table.TransformColumnTypes的参数是成对出现的列名和数据类型；Table.SelectRows里的each表示对每一行执行后面括号里的逻辑。这些都值夜班。

理解了刷新就是完整重放之后，一个常见困惑就能解开：为什么我在 Excel 里改了源数据单元格，Power Query 表却不变？因为查询默认读取的是你最初指定的源，如果你用的是普通区域，源是一个静态快照；只有把源数据定义成“超级表”（快捷键 Ctrl+T），查询的源才会有动态引用的概念。刷新一次，Power Query 就把从源到最后一步的所有逻辑从头执行一遍，这也解释了为什么刷新按钮叫“刷新”而不是“更新”——它不是简单重算，而是整条流水线重新跑一遍。

3. 把数据接进来：从工作表、CSV 文件夹到数据库的三种导入路线

3.1 从当前 Excel 表导入：先把普通区域转成超级表

最常见的场景是，数据已经躺在某个 Excel 文件里，你要把它送进 Power Query。很多人直接在数据选项卡点“从表格/区域”，结果弹窗提示“无法找到表格”，然后就愣住了。原因很简单：Power Query 不认普通区域，只认“表”。

所以标准的做法是：先选中数据区域内任意一个单元格，按 Ctrl+T 把它转成超级表。弹窗里确认“表包含标题”是否勾选，因为默认情况下第一行会被当作列名。接着，切到“数据”选项卡，点“从表格/区域”，Power Query 编辑器就会打开，源数据已经变成了一个查询。

这里有个细节值得多说一句：超级表的名称会成为查询的“表名”，之后你写 M 引用它时用的是这个表名。如果你换了表名，之前查询里的引用会失效。另外，超级表有个天生的优势：你在源区域下方新增一行数据，Ctrl+S 保存后，Power Query 刷新时能自动把新行纳入范围；但对普通区域来说，因为源没有得到“表”这个身份，新加的行在刷新时可能根本不被读取。这算是初学者最容易踏空的一步，我见过不少同事卡在这个“无法找到表格”的弹窗上浪费了半小时。

如果你要导入的 Excel 文件不是当前文件，而是磁盘上的另一个文件，操作路径略有不同：在“数据”选项卡里选择“获取数据”→“来自文件”→“从 Excel 工作簿”，然后浏览到目标文件。Power Query 会把工作簿里的每个工作表、每个命名区域、每个超级表都列出来，你选中需要的那个即可。注意，这时候查询读的是整个工作簿文件，文件里任何一个表的改动，刷新后都会体现在查询结果里。

3.2 从文件夹批量导入：格式一致的文件再多也不怕

比单文件导入更让人头疼的，是几十个格式一致但分散在不同子文件夹里的 CSV，或者每个月一整套的 Excel 报表。传统做法是打开每个文件复制粘贴到汇总表，重复又容易错。Power Query 的“从文件夹”导入就是为了解决这种批量需求。

操作路径是：“数据”→“获取数据”→“来自文件”→“从文件夹”，然后在弹窗里填文件夹路径，比如C:\data\orders。点击确定后，Power Query 会生成一个查询，里面列出了文件夹下所有文件的名称、路径、大小、修改时间等信息，但还没有真正读取每个文件的内容。下一步才是关键：点预览列的“合并”→“合并文件”，它会让你选一个示例文件，你用这个示例文件定义清洗步骤，Power Query 会把这些步骤自动套用到所有文件上。

这个机制看着很美，但它默认要求：文件夹里所有文件表结构一致。一旦某个文件多了一列，或者某列类型变了，刷新时就报错。所以我在做这类导入时，一定会先对文件内容做一次“清洗兜底”，不直接套用示例步骤，典型做法是写一段自定义函数来统一处理每个文件。示例函数是这样的：

(文件路径 as text, 文件名 as text) => let 源 = Excel.Workbook(File.Contents(文件路径 & 文件名), null, true), 订单表 = 源{[Item="订单", Kind="Table"]}[Data], 清洗 = Table.SelectColumns(订单表, {"订单ID", "金额", "日期"}), 类型修正 = Table.TransformColumnTypes(清洗, {{"金额", type number}, {"日期", type date}}) in 类型修正

然后在装配查询里用Folder.Files获取文件列表，再调用这个函数：

let 文件列表 = Folder.Files("C:\data\orders"), 添加处理列 = Table.AddColumn(文件列表, "已处理", each 处理文件([Folder Path], [Name])), 展开结果 = Table.ExpandTableColumn(添加处理列, "已处理", {"订单ID", "金额", "日期"}, {"订单ID", "金额", "日期"}) in 展开结果

逻辑解释：Folder.Files返回一个包含每行一个文件的表；Table.AddColumn给每个文件调用一次处理文件函数，函数的两个参数分别是文件所在路径和文件名；最后用Table.ExpandTableColumn把函数返回的表里的列展开到主查询里。这样即使某个文件多出无关列，Table.SelectColumns也会把列集固定下来，运行起来稳定得多。

这里要给两个参数提醒：一是函数参数顺序一定要和调用时一致，否则很容易走出“文件名传错位”的故障；二是each是按行重复的动作，后面引用列名要加中括号，写成[Folder Path]而不是Folder Path，这一点新手几乎一定会写错一次。

3.3 从数据库导入：查询折叠是个好东西，但别太迷信界面

在企业里，数据往往不是 Excel 文件，而是落在数据库里。Power Query 连接数据库的方式和 Excel 文件不太一样：它不只是拉数，还承担了把计算下推给数据库的能力。进入路径是“获取数据”→“来自数据库”→“从 SQL Server 数据库”，填服务器名和数据库名。如果你对 SQL 熟练，也可以在“高级选项”里直接粘贴一段 SQL 作为查询源。

常见的做法是连接后，Power Query 会弹出导航器，列出库里所有表和视图。你点选一个表，它会在后台生成类似这样的 M 公式：

let 源 = Sql.Database("server01", "SalesDB"), 订单表 = 源{[Schema="dbo", Item="Orders"]}[Data], 筛选状态 = Table.SelectRows(订单表, each [Status] = "已完成") in 筛选状态

这段代码看起来只是读表和筛选，实际上有个非常重要的性能机制叫“查询折叠”。Power Query 会尝试把自己的步骤翻译成 SQL 语句，交给数据库服务器去执行，而不是把所有数据拉回本地再过滤。所以你在界面里做的筛选、分组、选择列，如果能被数据库执行，查询的响应速度会快很多。

但要注意，不是所有步骤都能折叠。比如你加入了一个自定义列，里面用到了某些复杂的自定义函数，Power Query 可能被迫把前面的步骤也一并拉回来本地计算，这时候你之前设的筛选条件就不生效了。想确认某个步骤是否还能折叠，可以在该步骤上右键，查看“本机查询”或“查看数据库查询”的可用性。为了让数据库查询尽量折叠，我一般会在连接时就写好 WHERE 条件，而不是把几百万行拉到 Power Query 里再筛。

4. 清洗与转换：拆分、合并、透视、分组，四个一线高频动作

4.1 拆分列和合并列：解决文本型脏数据的两个反方向

导入的数据经常带着一列里塞了多个信息的问题，比如“张三-北京-销售部”，需要拆成三列。选中这一列，在“转换”选项卡里点“拆分列”→“按分隔符”，输入-，Power Query 会按分隔符切成三列，自动命名为“姓名.1”“姓名.2”“姓名.3”。如果分隔符在数据里出现得很乱，比如有的行可能没有第三个段，拆出来的列数会不一致，Power Query 会用null填在缺失的位置。

拆分列还可以按文本长度、按大写字母转换位置等方式切，但这些用得不多。真正需要留意的是拆分后的数据类型会被判定为文本，哪怕拆分出来的是“20250330”这种日期序列，它也是文本，需要你再做一个“更改类型”的步骤。这种低级转换造成的性能浪费，通常就是一看查询计划才发现的。

合并列正好相反：把多列拼成一列，比如把“年份”“月份”合并成“账期”。界面操作是选中两列，右键“合并列”，选择分隔符。一个特别常见的坑是：当你合并之后，数值列会变成文本列。比如你有一个“数量”列和一个“单位”列，合并成“数量单位”后，后续如果还要对“数量”做数学运算，你会发现求和结果不对甚至报错。这是因为合并操作把数值强转成了文本。所以合并列要谨慎选择范围，或者合并后补一个“更改类型”恢复数值属性。

拆分和合并的界面操作对应的 M 函数分别是Table.SplitColumn和Table.CombineColumns。比如按分隔符拆分的 M 代码长这样：

Table.SplitColumn( 源, "姓名与部门", Splitter.SplitTextByDelimiter("-", QuoteStyle.Csv), {"姓名", "地区", "部门"} )

参数含义很直白：第一参数是待处理的表，第二参数是要拆的列名，第三参数是拆分规则，第四参数是拆分后的列名列表。QuoteStyle.Csv表示在 CSV 转义规则下识别分隔符，如果你要拆的数据里分隔符本身可以作为内容出现，比如“张三-北京-“销售-部””，这个参数就很有用。

4.2 合并查询和追加查询：多表关联和数据堆叠是两个方向的操作

有一点先要分清：“合并查询”是把两个表的行关联起来，类似 Excel 的 VLOOKUP，但比 VLOOKUP 灵活，它可以做左外、右外、内联、全外等多种连接；“追加查询”是把两个结构相同的表上下堆在一起，类似在所有数据末尾粘贴另一个表格。

先说合并查询。操作路径：“开始”→“合并查询”，第一个对话框选主表，第二个选关联表，然后点选两个表中匹配的列，最后选择连接种类。默认是“左外部”，意思是保留主表所有行，关联表里找不到匹配的行会用null填充。如果你要的是只留下匹配行，就选“内部”。合并之后，右侧关联表会整体变成一列，列名是“NewColumn”之类的，你需要点击这一列标题右侧的展开图标，选择要带进来的字段，然后确定。展开这一步非常容易翻车：很多人选了“使用原始列名作为前缀”之后，列名变得很长，后续引用特别别扭。我一般都会取消勾选前缀，让展开的列名简洁一些。

合并产生的 M 公式核心是Table.NestedJoin：

Table.NestedJoin( 订单表, {"客户ID"}, 客户表, {"客户ID"}, "客户信息", JoinKind.LeftOuter )

意思是以客户ID作为匹配键，把两个表关联起来，关联结果暂存在一个名为客户信息的嵌套列中。之后你还需要Table.ExpandTableColumn展开这个嵌套列里的字段，这就是为什么合并后总是多一步展开操作。

追加查询则简单得多。在“开始”→“追加查询”里选择“将查询追加为新查询”，把需要堆叠的查询加入列表即可。注意追加查询只检查列名是否一致，它不会帮你去重，更不会补全缺失列。如果你想合并不同结构的多个表，得先在每个表里用“删除其他列”保住共同列。

这里有一个我这几年反复见到的坑：合并查询时两个表的匹配列类型不一致。比如主表的“客户ID”是文本类型，客户表的“客户ID”是整数类型，合并结果里会大量出现null，看起来就像数据丢失。这不是数真丢了，而是类型不一致导致匹配失败。解决方案是合并前，在两边都各自做一个“更改类型”，把匹配列统一成同一种类型。排查方式也很简单，看合并后展开的那列是否大面积 null，如果有，先去检查匹配列的类型。

4.3 分组和透视：在界面里完成原本要写复杂公式的活

如果要对订单按省份汇总销售额，传统做法是插个数据透视表，或者写 SUMIFS 公式。但数据透视表每次刷新需要手动刷新数据源，SUMIFS 则难以应对行数变化。Power Query 的分组功能相当于把这些聚合逻辑固化进了查询里。

操作步骤：在“转换”选项卡点“分组依据”，第一栏选择分组列，比如“省份”，第二栏添加聚合操作，选择“销售额求和”，Power Query 会生成一个新表，包含“省份”和“销售额求和”两列。你也可以一次添加多个聚合，比如同时求销售额平均值、订单笔数、最大订单额等。

分组对应的 M 公式是：

Table.Group( 订单表, {"省份"}, { {"销售额合计", each List.Sum([销售额]), type number}, {"订单笔数", each Table.RowCount(_), Int64.Type} } )

这里each后面是聚合逻辑，List.Sum([销售额])表示对当前分组内的销售额列求和，Table.RowCount(_)表示统计当前分组内的行数，type number和Int64.Type是结果的显式类型声明。把类型声明写全，Power Query 在后续步骤中能少做很多类型推断，性能也会更好。

透视列是另一个高频操作。它把某列里不同的值变成列标题，比如把“季度”列里的“Q1、Q2、Q3、Q4”变成四列，每个单元格填对应数值。操作路径：选中“季度”列，“转换”→“透视列”，再选一个值列作为单元格内容。透视之后，表格行数会大幅减少，但会出现很多null空值，比如某个季度没有销售。这时要用“转换”→“替换值”把null替换成 0，以免后续计算时报错。

透视列的坑在于：如果你透视时选错了值列，或者值列里存在一对多的问题，透视结果会变成一个多对多的矩阵，列数爆炸。所以透视之前，最好先确认“行”由哪些列唯一确定，Q1 只有一行对应省份、产品这类维度才有意义。

4.4 用“创建参考”替代复制查询：保住一条可维护的链路

前面提过一次复制和参考的区别，这里再展开说：复制是复制当前查询的全部步骤，之后与源查询断开联系；创建参考则是新建一个查询，它的源是当前查询的输出结果，源查询任何一步的调整都会传导到这个参考查询上。

这有什么价值？比如你有一条很长的清洗查询，最终输出的是“订单明细_已清洗”。如果要在它基础上分别做“按月汇总”和“按产品汇总”，你不必复制两份完整的清洗步骤，只需右键这条查询，选“创建参考”，生成两个轻量查询，各自再只做分组聚合。上游清洗逻辑一旦需要修改，你只改一处，两个参考查询自动跟着变，维护成本大幅降低。

但有个副作用要知道：每次创建参考时，Power Query 会复制一份数据到内存里。如果上游查询处理的是 100 万行，而你创建了 5 个参考查询，内存里就会同时存在 5 份 100 万行数据，刷新时消耗会明显增加。所以参考查询适合下游轻量聚合，不适合继续做重型清洗。真正的重型清洗应该只保留一条主干查询，其余都从参考派生，这是我在实际项目里优化刷新速度时最常用的一种结构。

5. Power Query 常见问题排查：5 个让新手翻车的现场和对策

5.1 刷新结果不对但没有任何报错：多半是数据类型悄悄变了

现象：查询刷新后没有报错，但数字变成了一串看起来像“43831”的数值，日期变成了天数序号，或者金额列求和结果少了很多位小数。原因：导入数据时，Power Query 自动对列做了类型推断，某些列被识别成了文本或日期，后续做聚合时就会出现偏差，又因为类型转换被当成“可见步骤”里的一个隐藏细节而没被注意到。解决：在查询设置里加一步“更改的类型”，把每列类型显式固定下来，尤其是数字列、日期列和文本长度超过 15 位的文本列。记住，Power Query 的类型推断只信第一行几十行数据，不代表全列类型，遇到混合内容必须手动指定类型。

5.2 删除中间步骤后一连串步骤报错：步骤链是有依赖的

现象：在“已应用步骤”里删除了某一步，比如“删除的列”，下方好几个步骤立刻出现红色感叹号。原因：被删除的这一步产出的字段，被后面的步骤引用着，一旦上游字段消失，下游步骤找不到输入。解决：不要直接删除步骤，改成修改步骤内容。比如你要做的事是“不删备注列”，而是希望后面步骤不引用它，正确的做法是保留删除步骤，同时去修改后面引用逻辑，比如把筛选条件里的字段改为其他列。如果非删不可，务必先检查后面每一个步骤的公式栏，看有没有引用被删字段。高级编辑器里搜一下字段名，比肉眼检查更靠谱。

5.3 合并查询结果大量为空白：优先检查关联列类型和大小写

现象：合并两个表后，展开关联结果时发现很多null，但去看原始数据，两个表明明有对应值。原因：最常见的是关联列类型不一致，一个是文本，一个是整数，导致匹配不上；也有是关联列存在前后空格，或大小写不一致。解决：合并之前，在两个源查询里各加一步“更改的类型”，把关联列统一为同一种类型，再用“转换”→“修整”清除首尾空格，最后确认关联键格式一致。检查方法不复杂，在合并对话框里选完关联列，下方会显示“找到的匹配行数”，如果匹配数远小于总行数，八成就是类型或空格问题。

5.4 从文件夹导入后新文件导致刷新失败：结构一致性比文件数量更关键

现象：文件夹导入的查询原本好好的，某天新增了一个文件后刷新报错，提示“找不到列”或“无法转换类型”。原因：Power Query 按示例文件定义的步骤套用到所有文件，新文件某列名称变了、多了一列、或者某列数据类型不同，步骤就会失败。解决：在文件处理的函数开头，用Table.SelectColumns固定需要的列集合，再用Table.TransformColumnTypes统一类型，这样即使新文件多出无关列，也会被裁掉；如果遇到列缺失，需要先判断是否真的允许缺失，允许时可以用Table.SelectColumns配合Table.ColumnNames做动态列名筛选。另外，把新建的文件夹路径做成参数，下次路径变了不用改函数体。

5.5 查询刷新越来越慢：三步定位慢在哪一步

现象：查询在开发时很快，用了一周后越来越慢，刷新一次要十几分钟。原因：很多情况是因为查询把大量步骤放在读取后的早期阶段，比如先做类型转换再做筛选，或者合并查询在本地展开一个巨大的嵌套列。解决：用“视图”→“查询依赖”查看整体结构，然后右键每个步骤的“本机查询”检查是否可以下推，优先把筛选和分组往前挪。还有一个技巧：给查询设置一个“仅创建连接”的中间查询，把重型清洗单独保留，下游聚合基于创建参考，而不是每个报表都独立重跑一遍相同清洗步骤。

6. 把查询升级成可复用工具：参数、自定义函数与一次刷新习惯

最后一个进阶技巧，我会做一件事：把最常用的批量汇总做成“传参即用”的模板。具体思路是，用 Excel 单元格作为参数输入面板，Power Query 读取这些参数，再通过自定义函数处理文件夹里的所有报表，最后输出汇总结果。这样你下次换文件夹路径、改统计阈值时，不用进 Power Query 编辑器，直接改单元格，刷新一下就行。

先在工作表里选两个单元格用来输入参数，比如把“C:\data\orders”写在某个固定单元格，把用来筛选的最小金额阈值写在另一个单元格。然后新建一个空查询，用Excel.CurrentWorkbook()读取参数表中的值：

let 参数表 = Excel.CurrentWorkbook(){[Name="参数表"]}[Content], 文件路径 = 参数表{0}[文件路径列], 最小金额 = 参数表{0}[阈值列] in 文件路径

再把之前写的处理函数扩展一下，接收路径和阈值两个参数：

(文件路径 as text, 文件名 as text, 最小金额 as number) => let 源 = Excel.Workbook(File.Contents(文件路径 & 文件名), null, true), 订单表 = 源{[Item="订单", Kind="Table"]}[Data], 类型修正 = Table.TransformColumnTypes(订单表, {{"金额", type number}, {"日期", type date}}), 筛选行 = Table.SelectRows(类型修正, each [金额] >= 最小金额) in 筛选行

最后在装配查询中，调用这个函数时传入参数表中的值。之后每个月换新文件夹，你只需要改那个参数单元格，点一次“数据”→“全部刷新”，整条链路就重新跑一遍。这个习惯帮我省下了大量重复性劳动，也让团队里不会写 M 公式的同事也能用模板。

这几年最深的教训是：Power Query 的问题很少出在“不知道用什么按钮”，而是出在“没搞清步骤间依赖关系、没固定数据类型、没提前考虑源结构变化”。把这一条主线记在心里，遇到任何查询报错，先看步骤链，再看类型，最后看源，基本都能快速定位。希望这份入门手册能帮你在数据清洗这条路上少走几次弯路。

本文还有配套的精品资源，点击获取