企业官网建设流程全解析

影刀RPA实操指南：采集任务的断网重试与网络异常兜底

采集流程白天手动跑，断网了你肉眼看见、点一下重跑就行。真正要命的是凌晨挂机跑的定时采集：跑到一半路由器抽风，网页加载超时，机器人停在一半，早上起来一看数据缺了三分之一，日志里躺着一串报错。

这篇文章讲的就是怎么用影刀RPA给采集任务装上"网络保险丝"：断网了自动等、自动重试、重试还不行就保存进度、发通知，等你早上醒来它已经自己扛过去了。这套兜底方案是我挂机采集被坑了大半年才一点点补齐的，按这个框架改一遍，你的流程才敢真正离开视线。

先把话说在前面：网络异常没法消灭，只能兜住。所有方案的目标不是"不出错"，而是出错之后流程自己能恢复，恢复不了也能留下完整现场。

先认识网络异常的四种形态

兜底之前得知道敌人长什么样。采集中遇到的网络问题，我归成四类。

四种形态的处理优先级不同。前两种最常见，靠"等待加重试"就能解决大半；第三种要去检查指令的超时参数设置；第四种才是真正需要整套兜底机制的。动手前先跑一轮流程，把日志翻一遍，看你的报错集中在哪一类，别上来就全套堆上去。

第一道防线：把超时参数设置到位

很多"网络异常"其实是超时参数没设对。影刀RPA里跟时间相关的参数散在各处指令里，新手默认不填，系统给的默认值不一定适合你的网络环境。

重点检查这几个地方：

1. 打开网页指令：页面加载的等待设置，网络差的环境适当放宽
2. 等待元素出现指令：动态渲染的页面给足时间，一般设10到30秒
3. HTTP类指令：官方文档里HTTP下载的超时时间默认是300秒，另有"连接超时秒数"参数单独设置，请求慢的接口要把两个参数都过一遍
4. 数据库连接：MySQL查询大表超时是另一类坑，下面单独讲

我自己的原则是：宁可多等三十秒，不要提前报一次错。挂机任务跑八小时，多等的那些时间根本不心疼，但一次没兜住的报错就毁了整晚。

等待的艺术：三种等待指令别混用

网页自动化的等待是防网络抖动的第一道墙，影刀里有三种等待，用法完全不同。

固定等待（延时指令）就是死等几秒，只在知道页面固定刷新周期的场景用，比如点击翻页后等2秒让列表渲染。等待元素出现是智能等待，等到元素出现才继续，这是采集流程的主力，配合超时时间使用。还有页面加载类的等待，用于打开网页后确保文档加载完成。

常见的错误用法是全程用固定等待：网络好的时候白等，网络差的时候等不够。我的组合拳是"等待元素出现打底+短固定等待微调"，翻页后的标准序列是：点击下一页→等待新列表第一条元素出现（超时30秒）→固定等待1秒缓冲→开始抓取。

等待元素出现指令的超时时间里，元素没出现会触发它自己的失败分支或报错，这个失败正是下一节重试机制的触发点。

核心机制：While循环实现的自动重试

重试是整个兜底方案的心脏。逻辑很简单：把"可能因网络失败"的操作包起来，失败了就等几秒再试，试满N次还不行才认输。

# 伪代码：网络操作的标准重试骨架（影刀流程的对应结构）# 变量初始化retry_count=0# 已重试次数max_retry=3# 最大重试次数success=False# 成功标志# While条件循环：没成功且没超次数就继续试while(notsuccess)and(retry_count<max_retry):try:# 这里放可能因网络失败的指令，比如：# 打开网页 / 点击翻页元素 / 等待列表元素出现success=Trueexcept:retry_count=retry_count+1# 失败后别立刻重试，指数退避：等 5s、10s、20ssleep(5*(2**(retry_count-1)))print("网络异常，第"+str(retry_count)+"次重试")# 循环结束后 success 仍为 False → 彻底失败，走兜底分支ifnotsuccess:save_progress()# 保存断点（后面细讲）notify()# 推送告警

两个细节决定重试的成败。一是重试间隔要用递增间隔（第一次等5秒、第二次10秒），失败后立刻重试大概率还是失败，还会加重网络和目标站点的负担。二是重试次数别设太大，3次是我的上限，重试是恢复手段不是死磕，死磕会把一次小故障放大成整夜空转。

这个骨架做成一个子流程，名叫"02_网络重试包裹"，以后每个可能受网络影响的操作都套一层，一次编写处处复用。

Try-Catch-Finally：兜底机制的地基

上面的重试骨架里已经用到了Try-Catch，这里把影刀RPA异常处理机制讲完整。Try块放可能出错的指令，Catch块处理错误，Finally块放无论成败都要执行的收尾，End Try结束整个结构。

Catch块里要做的三件事，一件都不能省：

1. 保存错误信息：Catch可以拿到Try里的报错内容，存进变量后用打印日志写出来
2. 错误截图：把当前屏幕截下来存进按时间命名的文件夹，网络类报错的截图往往能直接看出是断网、弹窗还是验证页
3. 设置失败标志：给一个布尔变量赋False，让外层逻辑知道这一步失败了

Finally块的价值容易被低估：不管成功失败都要关掉弹窗、清空临时文件这类动作放这里，能避免"失败重试时上一轮的残留状态污染下一轮"。新手最典型的bug就是第一轮失败的弹窗没关，重试时点到的还是那个弹窗，越重试越乱。

分模块的异常处理粒度也要讲究：单条数据的抓取用小颗粒Try（坏一条跳一条），整个采集任务外层再套一个大颗粒Try（保证通知和进度保存一定执行），两层各司其职。

断点续采：断网恢复后从断的地方继续

重试解决"抖一下"，断点解决"彻底断了"。凌晨断网十分钟，重试三次全失败，这时候流程应该做的事是：记住采到哪了，然后体面地结束，而不是从头再来。

断点的实现靠一个游标变量，我常用两种游标：

• 页码游标：翻页采集时记录当前页码，写进本地文本文件或配置表
• 数据游标：记录最后一条已采数据的ID或时间戳，恢复时从这个位置往后采

恢复逻辑放在流程开头：先读游标文件，读到值就从对应位置继续，读不到（比如首次运行）就从第一页开始。每翻一页、每采一批，就把新游标写回文件，写文件这步不能省，我见过有人只在内存里记游标，流程一崩全忘光。

配合增量采集的设计（已采ID去重），断点续采的可靠性还能再提一层：就算游标丢了导致重复抓了几个页面，ID去重也能拦住重复数据进表。两套机制叠着用，才叫真正的兜底。

数据库写入的网络坑：2013报错与read_timeout

数据入库环节的网络问题很隐蔽，值得单独拎出来。用Python节点连MySQL写入采集数据时，跑大查询或写入大批量数据可能遇到报错"2013, Lost connection to MySQL server during query"，本质是连接超时被服务器掐断了。

官方文档给的办法很直接：调整pymysql连接的read_timeout参数，给足等待时间。

# 连接MySQL：read_timeout防止大查询被掐断importpymysqldefmain(args):conn=pymysql.connect(host='127.0.0.1',port=3306,user='your_user',password='your_pwd',db='your_db',charset='utf8',read_timeout=600)# 读写超时600秒returnconn

除了超时，写入侧还有两个稳定习惯：一是分批提交，一千条一批commit，别攒十万条一次写，网络一抖整批重来；二是写入操作也套重试骨架，数据库和网页一样会抖。批量插入时遇到Duplicate entry唯一值冲突报错，说明有重复主键，要么写入前先查重，要么用容错的插入写法，这个报错在官方报错文档里有专门条目。

如果写入的是飞书多维表格这类云端存储，API调用本身也要套重试，云端服务的限流比本地数据库更常见，收到限流响应就退避等待再发。

无人值守的报警链路：日志、截图、消息推送

流程半夜自己扛不住的时候，必须能把消息递出来。我的一套报警链路是三层。

第一层是运行日志：关键节点都打印日志（开始采集、翻到第N页、重试第2次、保存断点），日志要简洁有信息量。这里有个小坑：打印日志对超长字符串有截断，想把完整的报错堆栈或网页内容留下，写进文本文件更可靠。

第二层是错误截图：所有Catch块里都带截图，按"日期_时间_模块名"命名，早上排查问题先翻截图文件夹，比读日志快。

第三层是消息推送：彻底失败时发飞书或企业微信通知。飞书群机器人配置好Webhook后，用HTTP请求指令把错误摘要推到群里，几行指令的事。通知内容要写清三件事：哪个流程、卡在哪一步、已保存的断点位置，收到消息的人不用打开电脑就知道要不要紧急处理。

定时任务的错峰与环境保障

挂机采集的稳定性一半在流程，一半在环境。定时任务配置上有几条实测经验。

机器所在电脑要关掉自动睡眠，不然凌晨流程跑一半电脑睡了，什么兜底都救不了。多个采集任务别设同一个时间点，错峰排队，不然机器人挤在一起，单个任务变慢，超时报错成倍增加——很多"网络异常"其实是自己堵的。

影刀的机器人调度模式支持云端控制台下发计划任务，企业环境可以看机器人状态是空闲、运行中还是离线，离线状态的机器人不会执行任何计划任务，定时采集前确认在线很重要。另外计划任务执行时不能断点调试，所有兜底逻辑必须在编辑器里手动验证过再上线，这是我强调过很多遍的上线纪律。

夜间网络环境普遍比白天波动大，夜间任务的等待超时和重试次数建议都设得比手动运行时宽松一档。

进阶技能的补位：HTTP采集与OCR验证

网页采集之外，两条进阶路线的网络兜底也要跟上。HTTP接口采集时，请求失败重试、限流退避的骨架和网页一致，接口的返回状态码要先判断再解析，别拿一个报错页面的HTML去转JSON。HTTP下载类指令记得检查默认300秒的超时是否符合你的场景，大文件下载要调大。

有些站点网络恢复后会先弹验证码，这是很多人忽略的坑：网络兜底成功了，流程却卡在验证页。简单的图形验证码可以接OCR识别，影刀内置OCR或接第三方OCR都行，识别失败同样要走重试和告警链路。验证页出现频繁的话，说明请求频率太高了，降速比识别更治本。

手机端采集（ADB方案）在弱网下问题更多，手机端有专门的等待元素、等待图像指令，把网页端这套"等待+重试+断点"的思想平移过去，指令名不同、骨架一样。

工程化规范：把兜底做成标准件

兜底机制代码量大、逻辑琐碎，最忌讳每个项目重写一遍。我的做法是沉淀四个标准子流程：网络重试包裹、断点读写、错误记录（日志+截图+失败标志三合一）、告警推送。新项目像搭积木一样把它们插进主流程，半小时就能给一个裸采集流程装上全套保险。

命名沿用"编号_功能"的规范，调试时单独跑"网络重试包裹"子流程，手动断网模拟故障，看着重试间隔和日志输出，比等真实故障来验证快得多。每个兜底子流程的输入输出参数写清注释，三个月后你自己会感谢现在写注释的自己。

版本选择上顺带说一句：无人值守挂机对运行时长有要求，社区版每天30分钟的限制下，定时挂机跑大任务不现实，轻量日更任务够用；任务重了再考虑升级，先用好兜底框架，流程稳了再谈规模。

易错速查：网络异常排查清单

挂机出问题早上别慌，先对表。

学习资源

本文的重试骨架、断点读写、告警推送三件套，完整流程源码我放在代码仓库 home.linyan.cloud，可以直接参考改造，断网模拟的测试方法也写在源码注释里。官方帮助中心建议精读"等待页面加载超时"和"连接数据库2013报错"两篇，分别对应网页端和数据库端最容易踩的两个超时坑。

#影刀RPA #RPA自动化 #异常处理 #定时任务 #数据采集

作者：林焱