接入 WTAPI 写的第一个参数就是getLoginQrCode里的type——ipad还是mac。很多开发者随手一填就过去了直到上线后半夜掉线才发现这个参数决定了你的机器人能不能自己爬起来重连。这篇把两种协议在官WTAPI文档里能确认的差异讲清楚以及这个差异对无人值守运维的真实影响。先声明哪些差异是有依据的哪些是玄学搜iPad 协议和 Mac 协议哪个稳能搜到一堆哪个更抗封哪个存活率高的说法——这些没有官方依据本文一概不引用。官方文档里明确写出来的差异只有一个但它很关键登录验证环节的处理方式不同。维度iPad 协议typeipad)Mac 协议typemac)滑块验证不支持自动滑块支持自动滑块官方口径约 80% 自动通过验证方式必须走人脸滑块为主辅以验证码autoSliding参数必须传false传true启用自动滑块需要人脸时checkLogin返回data.url人脸链接—验证码场景—checkLogin有captchCode参数可提交这组差异看着只是登录麻烦程度的区别但它的真正影响在掉线重连环节。工程含义重连能不能自动化决定夜间可用率机器人的掉线不是会不会的问题是什么时候的问题。掉线后的重连流程是收到Offline事件 → 调getLoginQrCode(掉线重登必须传原 appId传空会生成新实例→ 扫码/验证 →checkLogin确认。关键就在验证这一步Mac 协议的重连可以基本无人化。自动滑块 80% 通过率意味着大部分重连不需要人参与剩下 20% 滑块失败的checkLogin支持captchCode参数提交验证码可以接打码流程或告警值班人员补一下。整体可做成全自动 人工兜底。iPad 协议的重连必须有人在场。人脸验证绕不开checkLogin会返回data.url需要本人点开完成人脸。凌晨三点掉线就要凌晨三点有人醒着。做 7×24 客服机器人的这是硬性约束。代码两种协议的登录与重连处理importtime,base64,requests BASEhttps://wx.chuapi.comHEADERS{X-finder-TOKEN:平台Token,# WTAPI 控制台「Token回调」页Authorization:Bearer Bearer,Content-Type:application/json,}defget_qrcode(protocolmac,app_id):拿登录二维码。首次 appId 传空;掉线重登必须传原 appIdpayload{type:protocol,regionId:440000}ifapp_id:payload[appId]app_id rrequests.post(f{BASE}/finder/v2/api/login/getLoginQrCode,headersHEADERS,jsonpayload,timeout10).json()datar[data]withopen(qr.png,wb)asf:# 二维码推给值班人员扫码f.write(base64.b64decode(data[qrImgBase64]))returndata[appId],data[uuid]defwait_login(app_id,uuid,protocolmac):轮询登录状态:0未扫码 / 1已扫码未登录 / 2登录成功auto_sliding(protocolmac)# ipad 必须 false,mac 可 truewhileTrue:rrequests.post(f{BASE}/finder/v2/api/login/checkLogin,headersHEADERS,json{appId:app_id,uuid:uuid,autoSliding:auto_sliding},timeout10).json()datar[data]statusdata[status]ifstatus2:returnTrueifdata.get(url):# iPad 协议:人脸验证链接notify_duty(f需要人脸验证,请处理:{data[url]})returnFalsetime.sleep(3)defrelogin(app_id,protocolmac):Offline 事件触发的重连new_appid,uuidget_qrcode(protocol,app_id)# 传原 appId 保住实例okwait_login(new_appid,uuid,protocol)ifnotok:alert(f实例{app_id}重连需人工介入)# 人脸或滑块失败兜底注意notify_duty通知值班这个设计用 iPad 协议它不是可选组件是架构必需品——没有人脸通知通道重连流程就是断的。用 Mac 协议它降级为 20% 异常情况的兜底。两种登录流程想亲手跑一遍对比的WTAPI 开发文档weiti.apifox.cn支持在线调试——目前提供 7 天接口调用权限后台附带 Demo 示例可供本地调试。接口路径与字段以文档实时内容为准。怎么选按运维形态对号你的场景建议7×24 无人值守客服/机器人Mac 协议重连自动化是刚需多账号矩阵运营Mac 协议几十个号靠人脸重连不现实有运维值班、能随时配合人脸iPad 协议可选单账号 POC 验证都无所谓先跑通再说但别忘了协议只是稳定性的一个变量把视角拉高掉线率的贡献度排序里协议类型并不是最大的那个变量。按经验排IP 环境 账号质量 操作频次 协议类型。IP 环境登录 IP 归属地和账号注册地不一致是风控触发的高频原因。getLoginQrCode的proxyIp(socks5和aid(AID 本地网络需 24 小时开机的本地设备两个参数就是管这个的多账号运营建议一号一 IP。账号质量官方文档的账号建议写得很直白——注册时长 ≥3 个月、已完成实名认证、使用官方客户端。新号、未实名号什么协议都救不了。操作频次「运维与风控规范」专区的红线要读超频操作引发的掉线换协议没用。协议选对解决的是掉线后能不能自动爬起来IP、账号、频次管好解决的是少掉线。两件事都做稳定性才闭环。