一、执行顺序——先做什么后做什么通过申请后的操作有严格顺序第一步调通过接口好友关系建立第二步查联系人详情拿到完整资料第三步改备注打标签本地管理就绪第四步发欢迎语客户感知到服务。顺序不能乱没通过就改不了备注还不是好友没通过就发不了消息陌生人发不了。先确保关系建立成功再执行后续动作。每步检查返回码前一步失败后续不执行。二、失败处理——通过失败怎么办通过接口可能失败返回1004限频、返回其他错误码实例异常。失败后不能放弃要进重试队列。重试有上限3次超限标记为需人工处理并通知管理员。欢迎语发送也可能失败通过成功但发消息失败。这种情况好友已经加了但没收到欢迎需要一个补偿机制——定时扫描已通过但未发欢迎的好友补发欢迎语。三、幂等保障——重复回调不重复处理好友申请回调可能重试5秒超时触发3次重试程序可能收到同一条申请多次。必须做幂等用申请的唯一标识申请人wxid申请时间做去重已处理的申请不再重复执行。幂等不做好会导致一个好友被通过多次实际只会通过一次但后续动作重复执行、发多条欢迎语。好友收到多条欢迎语体验很差。四、执行质量检查执行完一组操作后要检查质量通过成功了吗备注改了吗欢迎语收到了吗用定时任务扫描通过但异常的记录输出异常报告。执行环节对照执行要点做什么不做的后果顺序控制通过→查详情→改备注→发欢迎操作失败或乱序失败重试失败进队列重试超限转人工好友加了没服务幂等去重唯一标识去重不重复处理重复发多条欢迎质量检查定时扫描异常记录问题积累无人知执行环节代码import hashlib def handle_apply(apply): # 幂等去重 key hashlib.md5( f{apply[fromUser]}{apply[createTime]}.encode() ).hexdigest() if db.exists(apply_log, keykey): return # 已处理跳过 # 第一步通过 r api(acceptFriend, {wId: WID, wxid: apply[fromUser]}) if r[code] ! 1000: retry_q.put(apply) # 进重试队列 return # 第二步查详情 detail api(getContactDetail, {wId: WID, wxid: apply[fromUser]}) # 第三步改备注 remark f{apply.get(source,未知)}-{detail[data].get(nickname,)} api(setRemark, {wId: WID, wxid: apply[fromUser], remark: remark}) # 第四步发欢迎 r api(sendText, {wId: WID, toUser: apply[fromUser], content: WELCOME_MSG}) if r[code] ! 1000: db.mark(apply_log, key, statusneed_compensate) # 待补发 db.save(apply_log, {key: key, wxid: apply[fromUser], status: done})落地建议执行环节是好友管理的最后一公里做好才算真正自动化。四个要点里幂等最容易被忽略——不做好会导致客户收到重复消息体验极差。建议上线前用重复回调压测验证幂等逻辑。好友管理接口参数说明参考 Eyun 开发文档实例开通见 Eyun 官网。