接入 WTAPI 写的第一个参数，就是getLoginQrCode里的type——ipad还是mac。很多开发者随手一填就过去了，直到上线后半夜掉线，才发现这个参数决定了你的机器人能不能自己爬起来重连。这篇把两种协议在官WTAPI文档里能确认的差异讲清楚，以及这个差异对无人值守运维的真实影响。
先声明：哪些差异是有依据的，哪些是玄学
搜"iPad 协议和 Mac 协议哪个稳"，能搜到一堆"哪个更抗封""哪个存活率高"的说法——这些没有官方依据，本文一概不引用。官方文档里明确写出来的差异只有一个，但它很关键：登录验证环节的处理方式不同。
| 维度 | iPad 协议（type=ipad) | Mac 协议（type=mac) |
|---|---|---|
| 滑块验证 | 不支持自动滑块 | 支持自动滑块，官方口径约 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 BASE="https://wx.chuapi.com"HEADERS={"X-finder-TOKEN":"<平台Token>",# WTAPI 控制台「Token回调」页"Authorization":"Bearer <Bearer>","Content-Type":"application/json",}defget_qrcode(protocol="mac",app_id=""):"""拿登录二维码。首次 appId 传空;掉线重登必须传原 appId"""payload={"type":protocol,"regionId":"440000"}ifapp_id:payload["appId"]=app_id r=requests.post(f"{BASE}/finder/v2/api/login/getLoginQrCode",headers=HEADERS,json=payload,timeout=10).json()data=r["data"]withopen("qr.png","wb")asf:# 二维码推给值班人员扫码f.write(base64.b64decode(data["qrImgBase64"]))returndata["appId"],data["uuid"]defwait_login(app_id,uuid,protocol="mac"):"""轮询登录状态:0未扫码 / 1已扫码未登录 / 2登录成功"""auto_sliding=(protocol=="mac")# ipad 必须 false,mac 可 truewhileTrue:r=requests.post(f"{BASE}/finder/v2/api/login/checkLogin",headers=HEADERS,json={"appId":app_id,"uuid":uuid,"autoSliding":auto_sliding},timeout=10).json()data=r["data"]status=data["status"]ifstatus==2:returnTrueifdata.get("url"):# iPad 协议:人脸验证链接notify_duty(f"需要人脸验证,请处理:{data['url']}")returnFalsetime.sleep(3)defrelogin(app_id,protocol="mac"):"""Offline 事件触发的重连"""new_appid,uuid=get_qrcode(protocol,app_id)# 传原 appId 保住实例ok=wait_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、账号、频次管好，解决的是"少掉线"。两件事都做，稳定性才闭环。
