做PowerApps的人迟早会撞上一面墙——搜索和筛选。前几篇教程我们已经把控件、数据源和表单玩得挺顺，但真正把数据“用起来”，让用户在几千几万条记录里快速定位到自己想要的那几行，这往往是低代码开发的第一道分水岭。很多初学者会遇到这种情况：明明数据源里能查到数据，放到应用里就筛不出来，或者一输入搜索框整个列表卡死，再或者明明加了筛选条件，结果集却纹丝不动。这篇教程就是来解决这些事的。
我会用一套完整的实操逻辑，把PowerApps里搜索和筛选的底层套路、常用函数、界面组合方案、性能优化和排查思路一次性讲透。这篇文章适合刚接触PowerApps的初级开发者，也适合那些已经做了几个应用但一直被筛选逻辑折腾的中级用户。读完你不仅能写出能用的公式，还能明白为什么这么写，以及数据量大了之后怎么保证不卡。
1. 搜索和筛选的整体设计思路
1.1 先分清楚：你要的是“搜索”还是“筛选”
很多人把搜索和筛选当成一回事，其实在PowerApps里这是两种不同的交互模式，对应完全不同的函数和体验设计。
搜索指的是用户输入一段文字，系统在所有字段或者指定的几个字段里做模糊匹配，返回包含这段文字的所有记录。典型场景是顶部一个搜索框，输入“华”字，列表里所有客户名称、联系人、地址里带“华”的记录全部出现。核心诉求是“我不知道我要找的东西具体在哪个字段，我只给它一个关键词”。
筛选则不同，是用户通过明确的条件控件缩小范围，每个条件对应一个精确的字段值。典型场景是页面上几个下拉框，一个选“在库状态”、一个选“所在仓库”、一个选“入库日期范围”，点一下确定，只保留完全满足所有条件的记录。核心诉求是“我知道我要什么，我只是不想在一堆数据里翻”。
这两者的公式写法有本质区别。搜索通常用Search()函数，筛选通常用Filter()函数。如果混着用，比如想实现搜索却用了Filter，那结果往往是搜“华”字什么都出不来，因为Filter()的相等比较不会做模糊匹配。反过来，如果你希望用户选了一个精确状态值之后只显示完全匹配的记录，却用了Search()，那可能会把很多不相关的“相似”记录也带出来，看起来就很诡异。
1.2 核心函数选型的底层逻辑
PowerApps里跟搜索和筛选相关的核心函数有三个：Filter、Search、LookUp。每次我在带新人做应用时，都要先帮他们把这三个函数掰扯清楚，不然到后面一定会乱。
Filter是筛选的主力，它接收一个数据表和一组条件表达式，返回的是满足条件的所有记录的集合。它的特点是精确、强大、支持多条件联合，而且它的条件表达式是逐条计算布尔值的，写法极其灵活。只要是能返回true/false的表达式，都可以塞进去。
Search是模糊搜索的专用函数，它接收一个数据表、一个搜索词，以及一个或多个字段名，在所有指定的字段里做包含匹配。它不关心字段里有几个关键字，只要目标词出现，这一行就会被返回。
LookUp是返回单条记录的，它跟Filter很像，都接收条件表达式，但LookUp返回的是满足条件的第一条记录（也就是一行数据），而不是一个表。通常用于获取某个ID对应的详情，或者从另一个数据源里取一个关联字段的值。
选型的逻辑并不复杂：你要的是多条结果，还是单条结果？你要的是模糊匹配，还是精确匹配？先在脑子里回答这两个问题，再去想用哪个函数，基本不会跑偏。
1.3 数据源的差异决定了写法
这句话是个大坑，很多人不知道。同一个Filter公式，在不同类型的数据源上，行为是不完全一样的。
如果你的数据源是SharePoint列表、Dataverse（微软的数据平台表）或者SQL Server数据库，这些属于“支持委派”的外部数据源。所谓委派，是指PowerApps不用把整个表拉到本地再筛选，而是把筛选条件翻译成数据源的查询语句，让数据库自己先查一遍，只把结果集返回给应用。这种方式对大数据的性能至关重要。
但如果你的数据源是Excel表格、导入的静态表、Collection（本地数据集合）或者某些第三方连接器，这些属于“不支持委派”的数据源。PowerApps只能把整张表的数据全部拉到应用本地，再用内置引擎逐条计算筛选条件。如果你的表有2000行，本地筛选问题不大；如果有5万行，应用就会明显变卡，甚至直接超时。
，多个条件之间是逻辑“与”的关系，也就是必须同时满足。这一点要特别强调，因为很多人一开始会以为多个条件之间是“或”的关系。
实际项目中我见过太多人写出这样的公式：
Filter(设备表, 状态 = "在库", 仓库 = "A仓库")这个公式的意思是：状态等于“在库”且仓库等于“A仓库”，缺一不可。但有的业务场景其实想表达“状态是在库，或者仓库是A仓库”，那就不能放在同一个Filter里了，得写成：
Filter(设备表, 状态 = "在库" || 仓库 = "A仓库")注意PowerApps里逻辑“或”用双竖线||，“与”用双竖线&&。如果你不写运算符，只是用逗号分隔条件，那些条件是“与”的关系。
Filter的条件表达式可以自由组合，这给了我们很多灵活的玩法。比如筛选价格在某区间内的商品：
Filter(商品表, 单价 >= 50, 单价 <= 200)可以筛选带关键字的记录（但注意这是精确比较，不是模糊匹配）：
Filter(客户表, 客户名称 = "某科技公司")也可以结合StartsWith做前缀匹配：
Filter(客户表, StartsWith(客户名称, TextInput1.Text))这里StartsWith判断文本是否以某个字符开头。它的优点是支持委派（在能委派的数据源上），性能远好于模糊匹配，缺点是只能匹配开头，不能匹配中间内容。
实操中，我建议把Filter当成搜索筛选的核心骨架，所有复杂的查询都从它出发。
2.2 Search函数：灵活的模糊搜索
Search函数是模糊搜索的救星，它的语法是Search(数据源, 搜索词, 字段1, 字段2, ...)，在列出来的这些字段里查找包含搜索词的记录。
比如我的“图书查询Demo”应用里有一个图书表，用户输入一本书名或者作者名，我想要在“书名”和“作者”两个字段里都做模糊匹配：
Search(图书表, TextInput1.Text, 书名, 作者)这样用户输入“三体”，不管书名是“三体”还是“三体全集”，都能匹配上；输入“刘慈欣”，在作者字段里也能匹配上。
为什么不直接写多个Filter加||来实现模糊搜索？因为PowerApps里没有内置的“包含”函数。你可以用If、Text等组合判断，但写起来非常啰嗦，而且性能很差。Search天生就是干这个的。
需要注意几个点：
Search在支持委派的数据源上，搜索词匹配通常不区分大小写（具体看数据源策略），这点比自定义公式要省心。Search的第三个参数起是字段列表，可以传很多个字段，但不要传太多，每多一个字段，查询的开销就大一分。- 最后一个参数不能省略，至少要指定一个字段。
Search返回的仍然是一个表，所以你可以把它直接丢给Gallery（画廊控件）的Items属性，也可以嵌套在其他函数里用。
Search最适合的场景是全局关键词搜，比如列表页顶部那个全局搜索框。但要记住一个关键点：Search是“或”的逻辑，只要任何一个字段匹配就返回这一条。如果你需要“多个字段都满足”的模糊逻辑，那就得回到Filter的怀抱。
2.3 LookUp函数：单条记录精确返回
LookUp函数很多人用得少，但实际项目里它特别有用。它的语法是LookUp(数据源, 条件, 返回字段?)，返回的是第一条满足条件的记录，如果第三个参数不写，默认返回整条记录的第一个匹配项。
常见的用法是从关联表里取数据。比如我有一个“设备借用记录表”，里面只有设备ID，页面上要显示设备名称，光靠设备ID是不够的，于是我可以在标签控件里写：
LookUp(设备表, 设备ID = ThisItem.设备ID, 设备名称)这样就会从设备表里把匹配设备ID的那一行找出来，并返回它的设备名称字段。
也可以拿它来做数据校验。比如用户输入了一个员工编号，我想先检查这个编号是否存在：
If(IsBlank(LookUp(员工表, 员工编号 = TextInput1.Text)), "编号不存在", "编号存在")注意LookUp找不到记录时返回的是空值Blank()，用IsBlank判断是常见的套路。
还有一个容易忽略的用法是LookUp配合聚合函数使用。PowerApps里有CountRows、Sum、Average等聚合函数，但Filter先筛一个子集再把子集丢给聚合函数，会让公式变得很长。用LookUp配合聚合写法上可以精简一些，不过这个看个人习惯，不是必须。
还有一点很实用：当你只是想确认“有没有这条记录”时，LookUp比Filter性能更好，因为它找到第一条就停下来，不会像Filter一样把整个结果集都算出来。
2.4 多条件组合的经典写法
实际项目里，纯粹的搜索或纯粹的筛选都比较少，大多数场景是两者组合。一个典型的出货记录查询页面，顶部有一个关键词搜索框、一个日期范围选项、一个状态下拉框，列表需要同时响应这三个条件。
我常用的写法是：用一个公式把Filter作为外壳，然后在条件区里用If加IsBlank来动态判断每个条件是否生效。
设应用里有三个控件：TextInput1是关键词搜索框，Dropdown1是状态下拉框，DatePicker1是起始日期，DatePicker2是截止日期。那么画廊控件的Items属性可以写成：
Filter( 出货记录表, TextInput1.Text in 客户名称 || TextInput1.Text in 物流单号 || IsBlank(TextInput1.Text), If(IsBlank(Dropdown1.Selected.Value), 状态 = 状态, 状态 = Dropdown1.Selected.Value), 出货日期 >= DatePicker1.SelectedDate, 出货日期 <= DatePicker2.SelectedDate )这里有个细节要说明：TextInput1.Text in 客户名称是PowerApps里的另一种“包含”判断，可以判断某个字符串是不是另一个字符串的子串，但它的局限是不能直接表达“在多个字段里任选一个匹配”，所以要么用||展开多个字段，要么用Search再包一层。上面的写法里，关键词部分我用了||把两个字段的判断都包含进来，再配合IsBlank让搜索框为空的时候不约束结果。
但说实话，公式这么长，维护起来有点痛苦，后面我会讲怎么把它拆成代码块的写法，让应用更好维护。
3. 界面控件的组合实战
3.1 搜索框与筛选控件的配合
要让搜索和筛选在界面上真正好用，不能只靠一个搜索框孤军奋战。我自己的项目习惯是：列表页顶部固定一个搜索区，里面从左到右排布搜索框、状态下拉框、类别下拉框和日期选择器，下方才是画廊列表。
搜索框用TextInput控件，它的Default（默认值）属性一般留空。下拉框用Dropdown或ComboBox，区别在于ComboBox可以多选，Dropdown只能单选。如果业务上某个字段允许多种状态同时查看，用ComboBox更合适；如果只是单一筛选，Dropdown更简洁直观。
日期范围我这里要特别说一下：PowerApps的DatePicker控件本身不提供“范围”概念，你需要两个DatePicker分别当起始和截止，然后在公式里比较。不少新手只放一个DatePicker就去筛日期，结果只能筛出等于某一天的数据，这显然不符合业务预期。
控件之间要做到联动，最省事的方法是把它们全部丢进同一个Gallery的Items公式里。但如果你有多个Gallery或者需要在别的页面也用同一套筛选逻辑，纯靠公式复制一遍会非常难维护。这时候建立一个“筛选状态集合”（Collection）是最舒服的做法。
3.2 Collection状态集管理筛选条件
Collection是PowerApps里的本地数据集合，可以通过Collect函数把数据存到应用内存里。它的典型用处之一就是暂存筛选条件。
我做过一个“客户关系管理Demo”的应用，顶部有超过6个筛选条件，我一开始把全部条件写在一个长的Filter里，后来改需求时改得怀疑人生。后来我改成先在按钮或者OnChange事件里把条件统一更新到一个Collection里，然后画廊的Items直接引用Collection里的值。
举个例子：
Collect(筛选状态, {关键词: TextInput1.Text, 状态值: Dropdown1.Selected.Value, 开始日期: DatePicker1.SelectedDate, 结束日期: DatePicker2.SelectedDate})每次用户修改任何一个筛选控件，我就把这条唯一记录重新Collect进去，再通过First(筛选状态).关键词这种方式在各处引用。
这种方式最大的好处是逻辑集中、排查方便。你在Screen的OnVisible事件或者全局的变量更新区把筛选状态维护好，界面上所有依赖它的控件都只做“取值”，不会出现一个变量在一个控件里定义、在另一个控件里修改、在第三个控件里引用，最后不知道在哪一步被改坏的悲剧。
这个方案也有一个小坑：Collect是追加式的，同样的数据会被重复插入，所以要么在Collect之前先Clear(筛选状态)，要么用Set变量当临时值的载体，再结合Collect统一汇总。我自己的习惯是能不用Collect频繁累计就不累计，多写一个Clear保平安。
3.3 让筛选结果实时响应与空白处理
实时响应是搜索筛选体验的灵魂。你肯定不希望用户每敲一个字还要点一下搜索按钮，PowerApps的控件变化本身就能驱动公式重算，问题只在于你有没有把逻辑放到正确的位置。
在PowerApps里，任何控件属性引用了变量或控件值时，这个属性的值会随着依赖项变化而自动更新。也就是说，Gallery的Items属性只要引用了TextInput1.Text，用户每次输入一个字符，Gallery就会立刻重新计算。这本身是天然支持“实时”的，不需要额外的事件代码。
但实时响应对性能压力很大，尤其是数据源不支持委派、数据量又大的时候，每敲一个字符都可能触发一次全表筛选。在后面的性能章节我会给具体的优化方案，这里先提一个基本思路：搜索框里加一个防抖机制（延迟响应），或者把搜索触发从“每字符变化”改成“按回车/点按钮”，能显著减少无谓的计算。
空白处理是另一件容易被忽略的事。用户输入了搜索关键词，但结果集为空，画廊里一片空白，毫无提示，用户的第一反应是怀疑应用坏了。我在画廊上方放一个Label，它的Text属性用If(CountRows(筛选结果) = 0, "没有找到符合条件的数据，请调整筛选条件", "")来提示，同时在画廊的Empty属性（如果使用画廊自带的空态样式）做配置。这个细节虽然很小，但在实际交付中的应用里，几乎每次都会被业务方称赞“想得周到”。
4. 性能优化与委派问题
4.1 委派（Delegation）机制详解
要说PowerApps搜索筛选里最大的隐形杀手，非委派问题莫属。我在做“某跨平台设备管理系统”时，模拟数据源有8万条设备记录，刚开始直接用Filter(设备表, StartsWith(设备编号, TextInput1.Text))写，在本地测试的时候只有几百条数据，速度飞快。可数据一上线，只要用户一输入搜索词，整个应用就要等十几秒，最后还会弹出黄色警告条，提示“此查询可能需要更多时间才能完成”。
这个问题的根因就是委派。PowerApps本身不在手机或浏览器端执行数据查询，它会把公式翻译成数据源支持的查询请求。但问题是，很多函数组合是无法被翻译成后台查询语句的，比如：
Filter(数据源, SomeFunction(字段) = "值")，SomeFunction如果是不支持自定义函数的组合，就无法委派。Search(数据源, TextInput1.Text, 字段1, 字段2)在SharePoint和Dataverse里支持委派，但在某些第三方连接器上不支持。- 如果你把数据源放到一个Collection里再筛选，那恭喜你，整个集合已经被拉到本地了，任何筛选都是本地筛选，不支持委派。
简单判断标准是：凡是PowerApps能在数据源层面直接翻译成查询条件的，就支持委派；凡是需要PowerApps自己把本地数据逐条评测的，就不支持委派。
4.2 数据量大时的处理策略
数据量上了万行之后，你的设计策略必须跟几千行时完全不同。我总结了三个方向：
第一，优先选择支持委派的数据源。Dataverse、SharePoint和SQL Server是PowerApps支持委派最完善的三类。如果你的业务数据量大且后续会持续增长，强烈建议用Dataverse或者SQL，而不是Excel。很多项目团队一开始图省事把数据放Excel，结果增长到几万行后应用根本没法用，再迁移成本极高。
第二，用“部分筛选 + 搜索”的混合模式。不要试图在一条公式里一次性跑完最复杂的查询。比如可以先按默认条件（比如执行人=当前用户）筛出一个几百条的子集，把结果Collect到本地Collection里，然后再在这个Collection上做Filter和Search。这就相当于把“远程查询”和“本地二次筛选”做了合理切分。要注意的是，这个方案默认你不需要跨全表做深度搜索，或者在业务上只允许用户搜索自己相关的数据，很多时候这反而更符合权限需求。
第三，搜索词后面加Trim和长度判断，防止空搜索把所有数据拉出来。写公式时养成习惯：
If(IsBlank(TextInput1.Text), 数据源, Search(数据源, TextInput1.Text, 客户名称))这个写法在搜索框为空时直接返回原始数据源本身，不触发任何搜索，能够大大减少无效计算。
很多人实际操作时会发现查询还是很慢，但搞不清是公式问题还是数据源问题。我的排查习惯是：先把所有筛选公式去掉，只保留最原始的数据源一下，看响应速度；如果原始加载都慢，那问题多半在数据源连接或者表结构上；如果原始加载快、加上筛选就慢，那再从支持的函数组合上找原因。
4.3 本地Collection的缓存优化
本地Collection是最值得推荐但也要慎用的性能优化手段。它的优点极其明显：数据在应用内存里，后续任何搜索筛选都不再依赖网络请求，速度响应成数量级提升。缺点同样明显：内存占用、数据同步延迟、不支持超大数据量。
一个比较稳妥的做法是：在应用启动或者打开列表页时，把本次会话需要用到的基础数据表按筛选条件拉一个合理子集，存进Collection里，然后后续所有筛选都在这个Collection上进行。比如库存查询应用，设备总数8万条，但你只关心当前用户在库的几千条，那就在App.OnStart或者Screen.OnVisible里执行：
Clear(本地设备缓存); Collect(本地设备缓存, Filter(设备表, 保管人 = User().Email))然后用Gallery的Items设为：
If(IsBlank(TextInput1.Text), 本地设备缓存, Search(本地设备缓存, TextInput1.Text, 设备名称, 设备编号))这样用户搜索时所有计算都在本地内存里运行，网络不会参与，流畅度是非常好的。
这个方案的坑在于，Collect时虽然拉的是子集，但如果子集本身有几万条，内存占用会非常可观，有些低性能设备或Web浏览器会有卡顿风险。稳妥的边界是单次Collection控制在1万条左右，超过之后果断回归委派查询模式。另外，如果数据源的记录经常变化，缓存策略要配合“下拉刷新”或定时重新拉取，否则用户看到的是过期的数据。
5. 常见问题排查与避坑指南
5.1 搜索不生效，先查大小写和数据类型
搜索不生效是我见过最多的报障，十有八九是数据类型不匹配或者公式里的大小写问题。PowerApps的公式本身不区分大小写，filter跟Filter一个意思，但数据源里的字段值可能区分大小写，尤其是某些数据库。
我之前遇到过一次SharePoint列表的文本字段，明明搜“ABC”有数据，搜“abc”就是空的。排查了很久，最后发现是SharePoint联机列表的某些字段排序规则导致的匹配差异。解决办法是统一用Lower或者Upper函数做规范化：
Filter(客户表, Lower(客户编号) = Lower("ABC123"))在Search函数里，如果遇到大小写敏感的数据源，也可以先把字段值和搜索词都转成小写再做匹配，但注意这样做的副作用是失去委派支持，所以大数据量时要权衡。
还有一个非常常见的坑：数字和文本的转换。PowerApps里输入框出来的一律是文本，哪怕你输入的是“123”。如果你拿它去比较一个数字类型字段：
Filter(订单表, 订单号 = TextInput1.Text)订单号如果是数字类型，等于比较时会有隐式转换问题，在很多数据源上会查询不到。稳妥的写法是加一个Value()转换：
Filter(订单表, 订单号 = Value(TextInput1.Text))但Value()转换之后同样可能丢失委派支持，所以在数据量大的表上建议把搜索字段设置成文本类型，避免这种转换。
5.2 下拉框筛选失效的排查思路
下拉框筛选失效，绝大多数情况是因为下拉框的值取错了。Dropdown控件有两个容易混淆的属性：Selected.Value和SelectedText（不同版本叫法略有差异）。虽然大部分场景Selected.Value是正确的，但如果你下拉框的Items是一个表，里面有几个字段，Selected.Value默认取的是Value列的值。如果这个列是空的，那筛选条件自然就是空。
我踩过的一个具体坑：下拉框的数据源来自一个“仓库表”，里面字段是仓库ID和仓库名称。我设置Items时用的是仓库表.仓库名称，但Selected.Value在我这个版本里取的是仓库表里没有定义Value字段的表，所以取出来总是空。最后改成Dropdown1.Selected.仓库名称才解决。
排查这类问题，最快的方法是在页面上放一个标签，直接显示Dropdown1.Selected.Value看它到底是什么值。你马上就能判断出是取错了字段还是数据源本身有问题。筛选条件加了没反应，先看条件值的类型和实际内容，别急着怀疑公式。
5.3 空值（Blank）导致的筛选漏数据
PowerApps里的Blank()（空值）是个特殊的“值”，它不等于空字符串""，也不等于0。很多人在筛选时忽略了对空值的处理，导致数据明明存在却筛不出来。
比如在筛选“合同状态”时，部分历史合同的字段是空白的，你想让它们在用户不选状态时也显示出来。如果公式只写状态 = Dropdown1.Selected.Value，那么状态为空白的记录永远不会满足条件，因为它们连“等于”这个比较都不会被触发。解决方法是显式加上空值判断：
Filter(合同表, IsBlank(状态) || 状态 = Dropdown1.Selected.Value)同时，当你处理日期范围筛选时，也要先判断日期是否为空，否则空日期会被判定不满足任何区间条件，导致漏数。
另一个空值相关的陷阱是：Filter的条件里如果引用了某个控件，而该控件当前没有值（比如Dropdown2.Selected.Value是空），那么这个条件本身怎么处理？前面2.4节里用If(IsBlank(条件), 状态 = 状态, 状态 = 条件)来绕过这个情况，这招务必要理解。
5.4 避坑清单与自查口诀
把多年实战里的高频坑整理成一个小清单，大家写公式时照着自查一遍，能省掉大量调试时间：
- 搜索词为空时，是否直接返回全表？不加
IsBlank判断，空搜索会拖垮性能。 - 条件里用到数字或日期时，有没有从文本类型转回目标类型？
- 下拉框的
Selected.Value字段名是否是数据表里真实存在的字段？ - 多个条件是“与”还是“或”？逗号分隔的是“与”，
||是“或”，&&也是“与”。 - 大数据量时，公式是否支持委派？
Search和Filter里的自定义函数会破坏委派。 - 使用Collection缓存时，有没有在重新拉取之前清掉旧数据？
- 空值字段是否会漏数？加
IsBlank(字段)兜底。
我自己写搜索筛选公式时，脑子里始终有一条自查逻辑：先确认“我要的是表还是单条记录”，再确认“是精确匹配还是模糊匹配”，然后看“这个数据源支不支持我要用的函数”，最后补上“空值和空搜索的判断”。把这四步走完，绝大多数问题都能掐死在萌芽状态。
6. 多表关联与跨数据源搜索
6.1 用LookUp补齐关联字段
PowerApps的实际项目很少有只靠一张表解决的，最常见的场景是“主子表”：一张设备表，一张借出记录表。列表页展示的是借出记录，但业务人员想按设备名称来筛选，设备名称在设备表里。这时候如果直接筛选借出记录表，是没法按设备名称做条件的。
我用的方案是：先给每个记录计算出一个“关联显示名”的字段，再在这个计算字段上做筛选。做法是在数据加载时通过AddColumns函数给子表临时加上一个字段：
ClearCollect( 借出缓存, AddColumns( 借出记录表, "设备名称", LookUp(设备表, 设备ID = 借出记录表.设备ID, 设备名称) ) )这样本地Collection里的每一行都会带上对应的设备名称，之后Search(借出缓存, TextInput1.Text, 设备名称)就能直接搜索关联字段了。这个做法在小数据量下非常好用，极大的简化了跨表搜索的写法。
但要注意，如果借出记录有几万条，你为每条记录都去LookUp一次设备表，本地Collection加载时间会非常长。这种场景的正解是反过来：先把设备表加载成Collection，用Filter从设备表里先筛出匹配的ID列表，再用Filter(借出记录表, 设备ID in 符合条件的ID集合)从借出表里获取记录。这样从“每条记录查一次关联表”变成“先缩小关联表再查子表”，性能好很多。
6.2 跨数据源搜索的限制
如果你想把“客户表”（在SharePoint）里的数据跟“订单表”（在SQL Server）里的数据合并搜索，PowerApps的Search和Filter一次只能作用于一个数据源。要跨数据源就得用Collect先把两边的数据分别拉出来，再合并到一个本地集合里。
常见的做法是：
ClearCollect(合并表, AddColumns(客户表, "来源", "客户"), AddColumns(订单表, "来源", "订单") )然后对合并表做搜索。这种方案灵活度高，但本质上是本地数据处理，只适合数据量可控的场景。一旦合并后的总量超过几万行，普通浏览器跑起来就会非常吃力，需要加以限制。
跨数据源搜索里还有一个坑是字段名不一致。两个数据源里同一个企业名称，一边叫“公司名称”，一边叫“客户名称”，合并时要统一命名，否则搜索条件里的字段引用会混乱。用AddColumns顺手把字段名规范化是一个一劳永逸的办法。
7. 从入门到进阶的经验心得
做PowerApps搜索筛选做到一定阶段，你会发现公式本身不难，难的是整体的思路和架构。我把自己后期积累的经验记在这里，可以作为少走弯路的参考。
一是公式尽量短。很多人喜欢把十几个条件塞进一个Filter里，看起来“一步到位”，但后期维护时根本不敢改。我的习惯是：能拆成With块的结构就先拆开，把中间计算结果暂存在本地变量或Collection里，再继续下一步。在PowerApps里，写一个长长的公式远不如分几步清晰。
二是变量名要规范化。项目大了之后，搜索框、下拉框、画廊、状态集之间的引用关系复杂，如果变量名随意，很容易改坏。我的命名习惯是：搜索框加_input后缀、下拉框加_ddl后缀、状态集统一用_filterState前缀。虽然PowerApps的变量名不支持完整匈牙利命名法，但养成带前后缀的习惯能显著降低认知负担。
三是不要吝啬做空态界面。搜索和筛选一定会出现无结果场景，空态界面的价值被严重低估。一个友好的空态不只是显示一句“无数据”，最好配上调整建议和清除筛选的快捷按钮。我在空态上放一个“重置筛选条件”的按钮，把几个筛选控件清空，这个交互在业务验收时经常被单独表扬。
四是善用With和App.OnStart管理初始化逻辑。每个新用户打开应用时，应只加载必要的初始数据，不要一股脑把全部数据拉进来。在App.OnStart里用If(IsEmpty(本地缓存), Collect(...))做初步加载，后面搜索筛选就有了缓冲基础。
五是记得在完成基础功能后做一次真实数据压力测试。我实际参与过的项目里，十有八九的搜索筛选问题是在真实数据量下才暴露的。模拟几百条数据测不出委派问题，也测不出Collection缓存的性能瓶颈。上线前用生产数据的副本压测一次，能避免很多生产环境的紧急修复。
这套搜索筛选的知识体系并不是孤立存在的，它和PowerApps里的表单、导航、权限模型、组件化设计都有关联。但先把“搜索筛选”这一条线吃透，你对PowerApps整个开发模型的理解会被往前推一大截。找到最需要的记录，是几乎所有业务应用的起点。
