UiPath网页自动化：获取元素集合实现遍历点击的完整指南

做 RPA 项目，尤其是网页自动化，最常被问到的需求之一就是这个：把页面上同一类元素一个一个点过去。比如逐条审批流程、逐个打开搜索结果、逐项点击菜单确认页面状态。拿 UiPath 来说，用鼠标录制一个点击很简单，但面对动态数量的元素，录制这条路就走不通了。本文就围绕“UIPath 获取网页元素做遍历点击的实现”展开，把获取元素集合、写动态 Selector、循环点击、处理各种意外情况的完整思路拆开讲一遍。

写这篇文章的起因是我经手过好几个 UiPath 项目，前期需求描述都是“把这个列表里的内容全部点一遍，把详情页数据存下来”，听起来像是一个 Click 活动的事，实际做起来牵扯到元素集合的获取、Selector 的稳定性、页面上下文切换，还有各种运行时异常。把这段经验整理出来，希望能帮到正在做类似需求的同学，尤其是刚接触 UiPath 网页自动化的朋友。

1. 为什么页面自动化里最常被点名的需求是“遍历点击”

1.1 一个每天都在重复的场景

先描述一个最典型的场景：某个后台管理系统的待办审批列表，每天都有几十条新记录。业务人员需要一条条点进详情页，点“通过”或“驳回”，再返回列表处理下一条。人工操作一天下来非常枯燥，而且容易漏点。用 UiPath 做自动化时，最直接的想法就是录一个点击的序列：先点第一行，处理完返回，再点第二行……

问题在于，列表里的条数每天不一样，行号也每天都在变。如果流程里写死“点击第三行”，那天只有两条记录就会出错，有三十条记录时又只能处理前三条。要真正解决这个问题，必须让流程自己去发现“当前页面上有多少个可点击的元素”，再逐个去处理。这个需求，就是典型的遍历点击。

1.2 遍历点击与普通点击的本质差异

普通点击，是“我知道我要点哪个元素，所以我告诉 UiPath 这个元素的特征”。比如某个按钮有固定的 id 或者固定的文本，UiPath 直接根据 Selector 定位过去，一次点击就完事。

遍历点击则不一样。它面对的是一个元素集合，集合的大小、顺序、内容都可能动态变化。流程要做的是先获取这个集合，再通过循环挨个处理。两者的底层差异，决定了方案的完全不一样：

• 普通点击可以硬编码 Selector，遍历点击一般需要通配符或动态 Selector。
• 普通点击不需要考虑“元素是否存在”，遍历点击必须考虑集合为空、元素被重新渲染等边界情况。
• 普通点击完后流程就结束了，遍历点击中每次点击后页面可能跳转，流程还需要负责“回到列表页继续下一次点击”。

所以，什么时候该用遍历点击？只要满足“同类元素 + 数量动态 + 每个元素都需要逐个操作”这三个特征，就是一个适合遍历点击的场景。反过来，如果列表数量固定、内容不变，那老老实实录个固定点击反而更省事，没必要强行上循环。

1.3 什么时候该用遍历点击，什么时候不该用

这点很多人会忽略，但我在项目评审时几乎每次都会提。遍历点击虽然灵活，也有它的成本和风险：每次循环都要重新定位元素、等待页面加载，运行速度明显比普通点击慢；而且页面只要一刷新，之前获取的元素引用就可能失效，需要额外处理。

如果页面的元素数量固定，比如一个固定的导航栏只有五个菜单项，那就别用遍历；如果元素的顺序和数量都稳定，用几个独立的 Click 活动按顺序执行，维护起来更直观。如果数量经常变、内容经常变、甚至不同用户的待办数量都不一样，就必须用遍历点击。先判断场景归属，再动手写流程，能省掉后面很多不必要的麻烦。

2. 获取网页元素集合：先搞懂 Find Children 和 Get Ui Elements

2.1 Find Children：经典玩法

在 UiPath 里，获取多个网页元素最常见的方式是“Find Children”活动。这个名字可能容易让人误解，它并不是“查找子级”那么简单，它的作用是：在你指定的某个容器元素（比如列表的 div、表格的 tbody、菜单的 ul）下，筛选出所有符合条件的子元素。

Find Children 的参数有讲究。它有一个“作用域”的概念，你需要先指定一个容器作为锚点，然后在容器内部按 Selector 过滤子元素。输出是一个 UiElement 数组。

例如一个待办列表：

<ul class="todo-list"> <li class="todo-item"><html app='chrome' title='待办中心' /> <webctrl tag='BUTTON' type='button' txt='审批' />

它表达的意思是：在 Chrome 浏览器、标题为“待办中心”的页面里，找那个标签是 BUTTON、类型是 button、文本是“审批”的按钮。

调试 Selector 时，我推荐直接用 UiPath 的“UI Explorer”工具。安装扩展后，在活动面板里点“拾取元素”旁边的小箭头，就能打开 UI Explorer，里面可以看到页面的 UI 树，还能手动修改某个节点的属性，实时测试你的 Selector 能不能匹配到目标元素。改 Selector 的时候，右下角一般会显示当前匹配到的元素数量，这个数字非常有用。如果你填的通配符写错了，比如属性名拼错，匹配数会直接变成 0，当场就能发现。

3.2 通配符怎么写才不容易误伤

遍历点击场景里，最常用的技巧就是给 Selector 加通配符。UiPath 的通配符和文件通配符类似：

• *表示匹配任意多个字符
• ?表示匹配任意一个字符

举个例子，列表项如果 class 是动态的，比如有时是todo-item active，有时是todo-item pending，那 Selector 里可以写成：

class='todo-item*'

这样不管后面跟什么状态，都能匹配到。又比如按钮的文本在“通过”“驳回”“查看详情”之间变化，但都包含“批”字，可以写成：

txt='*批*'

不过这里有个重点：别为了“全”把 Selector 写得太宽。比如你写class='item'，也许页面上还有别的模块也叫 item，一下就把无关元素捞进来了。正确做法是给 Selector 增加约束条件：既要 class 匹配，又要 tag 匹配，必要时再加上父级节点限定。多个条件同时满足，才能保证筛出来的元素是我们要的那一拨。

3.3 缩小作用域：用父容器当锚点

Selector 写得再稳，也架不住页面上有大量相似结构。比如页面左侧菜单和右侧面板里都有 class 为list-item的元素，只靠单个元素的特征区分不出来。这时候就要靠“作用域”来帮忙。

Find Children 的设计思路正是如此：先可靠地定位父容器，再在父容器内筛选子元素，这样层级关系就锁死了。父容器即使 index 会变化，但如果它有一个稳定的业务属性，比如><div class="approval-container"> <div class="approval-item"><webctrl tag='DIV' class='approval-item' />

3. 输出设为一个名为approvalItems的 UiElement 数组变量。

此时approvalItems中就有了三个元素的引用。如果页面一次只显示 10 条，它就只有 10 条；要处理全部记录，就得先考虑下一页或滚动加载的问题，这个后面第五节再细聊。

4.2 第二步：For Each 循环里的点击安排

拿到集合以后，下一步是遍历。我会放一个“For Each”活动，遍历类型选择UiElement，遍历对象选approvalItems，循环体内放一个“Click”活动。

这里有一个很多新手会卡住的点：Click 活动的 Target 默认是让你“拾取一个元素”，而不是让你直接选一个变量。要点击当前循环项，方法是把循环变量item拖到 Click 活动上，或者把 Click 的 Target 类型改为“UIElement”，然后选中item变量。这样循环每跑一次，点击的就是当前这一个元素。

如果元素没有完全显示在可视区域内，点击之前最好加一个“Scroll Into View”活动，参数也指向item。某些网页上元素虽然在 DOM 里，但不在当前滚动区域，直接 Click 会被浏览器拦截或者提示“元素不可见”。先把元素滚到视野里，再执行点击，成功率高很多。

4.3 第三步：点击后的等待与页面恢复

遍历点击最容易被忽略的是点击后的“页面状态”。你点进去一个详情页，页面发生了跳转或弹窗，这时候直接进入下一轮循环去点击第二个元素，大概率会失败，因为页面已经不是刚才那个列表页了。

所以循环体内通常要分成三段：

• 点击前：等待目标元素就绪，必要时滚动到可见位置。
• 点击后：等待详情页加载完成。具体可以用“Wait Element Appear”等待详情页上的某个特定元素出现，或者用“Delay”活动给一个合理的缓冲时间。
• 回到列表：如果在详情页进行了操作，需要“Browser Back”或者点击返回按钮，然后再等待列表元素重新出现，才可以进入下一次循环。

注意一点：从详情页返回之后，原来的 UiElement 引用可能已经失效。如果只是返回同一条列表页，元素引用偶尔还能用；但只要页面有刷新，保险的做法是每次循环开始时重新获取一次元素集合，或者在循环开头等待列表容器重新出现。

4.4 一个最小可用模板

用文字描述不如给一个精简模板。以下是一个用 UiPath 活动搭建的最小可运行流程，大致顺序是：

1. 打开浏览器，进入待办列表页。
2. Find Element 定位列表容器container。
3. Find Children 获取所有审批项approvalItems。
4. For EachitemInapprovalItems：
   • Scroll Into Viewitem。
   • Clickitem。
   • Wait Element Appear 详情页标志元素（比如保存按钮）。
   • 执行详情页里的操作。
   • 返回列表页。
   • Wait Element Appear 列表容器。
5. 日志输出“遍历完成”。

这个模板本身很简单，但每一步都有值得优化的空间。尤其是第 4 步里的返回操作，如果详情页是打开新标签页，还要加一个“切换浏览器标签页”的活动，否则流程仍然停在旧页面。

5. 实际项目里踩过的坑：元素失效、懒加载、iframe 和弹窗

5.1 页面一刷新，之前拿到的 UiElement 就失效了

这是遍历点击里最常见的坑。UiElement 变量本质上是对页面上一个节点的引用，页面如果发生了刷新，原来的引用就断了，对它执行 Click 就会报错，提示类似“元素不存在”或“选取器超时”。

解决方法分两种思路。

如果页面只是局部刷新，返回列表后列表节点被重新渲染了，那就不能一直复用最初的 UiElement 数组。比如每次点击后返回，原来的approvalItems[1]已经不再是新的列表项，这时候需要重新执行 Find Children。如果担心重新获取后循环会从头开始，可通过记录当前项的标识（比如文本内容），在重新获取后先定位到该项的位置，再继续。

如果页面完全没有刷新，只是发生了滚动或弹窗遮挡，那引用一般还有效，直接在新一轮循环里对剩余元素继续操作即可。判断的关键是：页面有没有发生实质性的 DOM 刷新。这个在开发时可以通过观察运行日志和截图来判断。

5.2 元素没在首屏，Find Children 就抓不到

现在很多列表页都是懒加载。第一次打开页面，只有首屏 10 条数据；滚到底部，才会加载下一批。这种情况下，你直接 Find Children，拿到的一定只是首屏那几条，而不是全部。

处理思路很直接：在获取元素之前，先把页面滚动到底部，触发全部加载，再滚动回顶部，让首屏元素可见。然后执行 Find Children。如果数据量特别大，滚动一次还不够，就需要循环执行“滚到底部 -> 等待加载 -> 再滚到底部”，直到页面底部不再出现新的内容。

另外，滚动动作之后要加一个短延迟，比如 1 到 2 秒。因为懒加载是异步的，滚动之后元素还没渲染出来，立刻去找就可能拿到不完整集合。宁可多等一会儿，也不要为了省时间而后面对不上数。

5.3 藏在 iframe 里的元素，作用域选错就是空列表

网页里嵌了 iframe 的情况，在后台管理系统中非常常见。iframe 相当于页面里嵌套了另一个独立文档，UiPath 默认的 Web 自动化作用域看不到 iframe 内部的内容。如果你发现 Find Children 返回空集合，第一反应就应该是：目标元素是不是在一个 iframe 里。

处理办法是先用 Find Element 定位到 iframe 元素本身，然后在 Find Children 里把这个 iframe 元素作为作用域容器。UiPath 支持在 iframe 内部继续查找子元素，只要作用域指对了，里面的元素就能正常拿到。

还有一种情况是页面里有多个同类的 iframe，比如多个嵌入面板。这种情况更要小心，别让 UiPath 定位错 iframe。可以优先用 iframe 的 id、name 或 src 属性来限定，不要只用 index。

5.4 点击后新弹窗/新窗口，循环上下文要切换

有的详情页不是在同一标签页打开的，而是新开一个标签页或弹出一个模态框。如果在循环体里直接继续点击下一个列表项，流程会找不到目标元素，因为当前焦点可能还在新窗口里。

针对新标签页，需要在点击后加一个“Attach Window”或“Switch Window”活动，把上下文切换到新窗口，操作完之后关闭或切回原来的列表页。针对模态框弹窗，可以把它当作一个普通元素来处理，用“Wait Element Appear”等待弹窗出现，处理之后点关闭按钮，等弹窗消失，再继续循环。

这里我习惯在整个循环开始之前，先把列表页的窗口引用存下来。这样即使后面切换了多个窗口，也能随时切回最初的列表页，而不是依赖 UiPath 自动判断当前窗口。

5.5 用“业务主键”而不是索引来定位剩余元素

遍历点击跑了一半突然失败，是很常见的事。失败后重新运行，如果流程是从头开始，前面已经处理过的数据会被再处理一遍，造成重复操作，比如重复审批、重复驳回。

解决这个问题的思路，我称之为“业务主键法”。在进入循环之前，先把列表里每条数据的唯一标识采集出来，比如单据编号、审批单号。在真正执行点击之前，先判断这个标识是否已经在“已处理集合”里，如果是就跳过。这样流程即使中途挂了，重跑时也能从上次断掉的地方继续，不会把已处理的数据再点一遍。

实现上可以在循环前用 Data Scraping 抓一列单号，存成一个集合变量。循环里每处理完一条，就把当前单号加到另一个集合。重跑流程时加载这个集合，循环内做一次包含性判断。这个方案虽然多写几步，但面对生产环境时非常值得。

6. 让遍历点击跑得稳的实用习惯：等待、异常和日志

6.1 等待活动怎么排列组合

遍历点击的运行稳定性，一半靠元素定位，另一半靠等待策略。UiPath 里常见的等待活动有：

• Wait Element Appear：等待某个元素出现。适合在点击后确认页面加载完成时使用。
• Wait Element Vanish：等待某个元素消失。适合等待加载动画结束、弹窗关闭等场景。
• Delay：固定延迟。适合已知需要几秒钟的异步操作，但要慎用，固定延迟不是最优解，能不用就不用。

我的组合习惯是：凡是页面跳转或刷新，都用 Wait Element Appear 等待目标页面的标志元素；凡是点击后出现的加载动画，都用 Wait Element Vanish 等它消失；只有等待时间确实无法用元素状态来判断时，才用 Delay。这样可以避免流程在慢速网络环境下频繁失败。

这里还要提醒一下，Wait 活动的“超时时间”要设置合理。单次元素加载等 10 秒通常够了，如果业务系统本身响应很慢，可以放到 20 到 30 秒。超时后再执行错误处理逻辑，而不是直接崩溃。

6.2 Try Catch 与 Retry Scope 的配合

遍历点击涉及大量循环，任何一次点击异常，理论上都不应该让整个流程崩溃。我会在循环体内包一层“Try Catch”，把点击、操作、返回这些步骤都放在 Try 分支里，Catch 分支统一记录异常信息，并且把当前数据项标记为失败，继续下一轮循环。

如果失败原因只是网络抖动或页面加载慢，那还值得重试。UiPath 里有 Retry Scope 活动，可以设置重试次数和间隔。我把重试逻辑放在循环内，比如同一项最多重试 3 次，每次间隔 5 秒，仍失败才记入失败日志。这个策略在生产环境里帮了我很多次，尤其是某些业务系统在特定时段响应特别慢的时候。

但重试也要考虑幂等性——如果点击后已经进入详情页并执行了操作，只是返回列表时超时，那重试同一个元素就可能导致重复操作。所以重试前最好先判断当前页面状态，到底是“还没点进去”还是“已经操作完但返回失败”。如果已经完成了操作，就不该再点，而是直接跳回列表页继续下一个。

6.3 循环里写日志，排错效率翻倍

写日志是很多人不做，但关键时刻能救命的事。在遍历点击的循环里，每处理一条数据，都值得记录以下几类信息：

• 当前处理的是哪条元素（比如单号、标题文本）。
• 点击前元素是否找到。
• 点击后页面等待是否成功。
• 本次循环耗时。
• 如果出现异常，把异常消息和堆栈记下来。

UiPath 里可以用 Log Message 活动实现。日志级别建议用 Info 记录正常流程，用 Error 记录异常。跑完一遍流程后，打开输出日志，只看 Error 级别就能快速定位失败在哪一条、失败原因是什么。如果没有日志，一旦列表量很大，你根本不知道流程跑到了哪里、在哪一步断掉的。

还有一个实用小技巧：在循环里的关键节点加“Take Screenshot”活动，把点击前后的页面截图保存到本地。当自动化结果有争议时，截图就是最直观的证据。截图命名可以带上当前元素的标识，比如“101_点击前.png”“101_详情页.png”，这样翻查起来一目了然。

7. 收尾：一点个人体会

做多个遍历点击项目之后，我最大的体会是：这个功能写起来不难，难的是让它长时间稳定运行。元素失效、懒加载、iframe、弹窗、网络波动，任何一个环节出问题，自动化都可能半路停工。所以如果你刚开始接触这个需求，别急着把循环跑通就算完，至少要在本地多测几轮，尽量模拟生产环境的数据量和网络条件。

另外，如果页面结构很乱，与其在 UiPath 里硬抠 Selector，不如找前端同事协调一下，让他们给列表项加一些稳定的自定义属性，比如>