影刀RPA进阶教程：API分页采集实战——page参数与数据完整性校验
用影刀RPA调接口采集数据，最常翻车的地方不是取不到第一页，而是翻页翻到一半漏数据、重复数据混进来，最后对账时发现库里少了两百条，谁也说不清丢在哪一页。这篇就把page参数翻页的写法和数据完整性校验的方法一次讲透。
我是非技术出身，第一次做分页采集时想当然地用固定页数循环，结果接口总数变了就漏采。踩过几回坑之后，我总结出一套"动态翻页+三重校验"的写法，跑了快一年没再出过数据缺失。
主线案例：采集某电商平台的商品列表接口，每页50条，总量动态变化，要求每天采集的数据一条不多、一条不少地入库。
HTTP请求指令：把接口响应摸清楚
一切从【HTTP 请求】指令开始。这个指令是影刀RPA客户端内置的，装好客户端登录就能用，不依赖浏览器插件；后面会讲到的网页自动化兜底路线才需要装浏览器插件。在右侧指令面板搜索"HTTP"就能找到，方法下拉支持GET/POST/PUT/DELETE/OPTIONS/PATCH等，URL填接口地址。如果手里有一段现成的cURL命令，影刀还支持"智能识别填入"，根据HTTP报文自动识别并填充各项内容，新手不用一项项手填。
响应结果保存为变量后，它包含四个部分，这是官方文档明确的：
| status_code | 状态码，以2开头表示成功，如200 |
| content_type | 内容类型，如application、json |
| content_encoding | 内容编码 |
| content | 响应内容本身 |
还有一个"连接超时秒数"参数，接口偶尔慢的时候别用默认值，设到30秒能少很多莫名失败。如果请求需要认证信息，勾选"通过网页发送HTTP请求"并选择已完成认证的响应网页，浏览器里的登录态就能带过去。
变量与数据类型：JSON解析是分页采集的基本功
接口返回的基本都是JSON，处理链路固定四步：HTTP响应→字符串转JSON对象→按键取值→转回文本落库。
这里牵扯三类数据类型的配合：
- 列表：JSON解析出的数据行通常是列表，list[i]取第i条
- 字典：每条数据是字典，按键名取值，取值前先判断键是否存在，避免报错中断
- 字符串：从JSON对象转回文本再写入Excel或数据库
第一页响应里通常有一个总数字段（total或totalCount之类）和当前页数据列表。先用【打印日志】把content打印出来看结构，确认字段名，再写解析逻辑，不要凭猜测写。
流程控制：While条件循环才是翻页的正解
新手最容易犯的错是用For次数循环写死页数。接口数据每天在变，今天80页明天85页，写死必出问题。正确做法是While条件循环，条件是"本页有数据就继续翻"。
# 翻页采集核心逻辑（伪代码，影刀指令对应实现）
page = 1 # 页码变量，初始为1
all_data = [] # 存所有数据的总列表
While True: # While条件循环
# HTTP请求指令：GET 接口地址?page={page}&page_size=50
response = HTTP请求(url, 协议头)
data = JSON解析(response.content)
rows = data["list"] # 当页数据列表
If 列表长度(rows) == 0: # 空页 = 翻完了
Break # 跳出循环
all_data += rows # 追加到总列表
page += 1 # 页码加1，采下一页
# 退出循环后进入完整性校验环节
有两个细节容易漏：一是循环里加【打印日志】输出当前页码，中断了能立刻知道断在哪页；二是在请求之间加一个【等待】指令隔1到2秒，太快容易触发接口限流，返回429状态码。
数据完整性校验：三道关卡缺一不可
数据采回来不等于数据是全的，我固定做三道校验：
# 完整性校验示例（Python协同）
# 输入：total 接口声明的总数；all_data 采集到的数据列表
# 输出：校验结果文本，写入日志并作为是否告警的依据
def check_data(total, all_data):
if len(all_data) != total: # 数量比对
return "数量不一致: 预期%d, 实际%d" % (total, len(all_data))
ids = [row["goods_id"] for row in all_data] # 提取唯一标识
if len(ids) != len(set(ids)): # 集合去重后长度变化=有重复
return "存在重复数据"
return "校验通过"
校验失败的处理方式是：不要静默通过，用If条件判断分支，失败就写飞书告警并把本次数据标记为待复查，宁可人工看一眼，也不能让残缺数据入库。
网页自动化与元素定位：接口采不到时的备用路线
有些接口有签名校验，直接请求会失败，这时退回网页自动化采集。元素定位还是四件套：元素捕获、XPath、CSS选择器、正则表达式，XPath和CSS按页面结构选，列表页我习惯XPath层级定位。
翻到网页分页时，"下一页"按钮的disabled状态是判断是否最后一页的标志：用【判断元素是否存在】检查带disabled样式的按钮，存在就停。无限滚动的页面用滚动加数据index去重的办法，滚动前后数据条数不变即为到底。这些逻辑和接口分页的While循环思想完全一致，学会一个另一个就通了。
数据处理与数据库落地：从二维列表到MySQL
采集完的数据要落地。整理成二维列表后，用【批量插入到数据库】指令写入MySQL，"单次连接插入数量"别用默认值，数据量大时改到50000，避免频繁连接断开出错。插入成功后会返回受影响的行数，拿它和校验通过的列表长度再比一次，这是第四道校验。
Excel也不能完全放弃，我每天会同步写一份Excel快照，出问题时人工翻查比查库快。
鼠标键盘图像、进阶技能与平台实战的分工
这套流程里其他模块各司其职：
- 鼠标键盘图像：遇到必须图形界面操作的环节（如验证码弹窗）才用，图像识别做兜底
- 进阶技能：HTTP请求和Python协同是本篇主角，OCR用于图片型验证码，ADB用于手机端接口
- 平台实战：小红书、淘宝、TEMU的接口结构不同，但page参数翻页的框架是通用的，换接口只改URL和解析字段
系统联动与工程化规范：定时采集与告警闭环
系统联动让流程闭环：采完发飞书群消息，内容带上"总数、实采数、校验结果"三个数字，扫一眼就知道当天数据质量。定时任务配置在每天凌晨跑，错开接口高峰。
工程化上，把"单页请求"封装成子流程，输入页码、输出当页数据；把"完整性校验"封装成第二个子流程，输入总列表、输出校验结果。主流程只剩循环和判断，命名按"010_请求单页"这种编号法。社区版每天30分钟时长跑不完大采集任务，这种量级建议上创业版。
易错速查：分页采集四大高频故障
| 采到的数据永远少最后一页 | 用固定页数循环，未判断空页 | 改While循环，空页Break |
| 每页都有重复数据 | page参数没生效，URL拼接错误 | 打印日志核对每页实际URL |
| 跑到一半返回429 | 请求频率过高触发接口限流 | 请求间加等待，失败后隔段时间重试 |
| JSON解析报错 | 响应其实是HTML错误页 | 先判断status_code是否2开头再解析 |
还有一条经验：翻页过程中如果某一页请求失败，不要整批作废，记录失败页码，流程结束后单独补采失败页，比全量重跑省时间。
学习资源
接口采集这块，官方有HTTP专题的视频课程，把请求和网页监听一起讲了，值得看。完整流程源码我放在代码仓库 home.linyan.cloud，动态翻页加三重校验的整个子流程都在里面，直接参考改造就能接你自己的接口。
#影刀RPA #RPA自动化 #数据采集 #API接口 #批量采集
作者：林焱
