做微信自动化这两年我前后经手了十几个项目。最开始接的时候我犯了大多数新手都会犯的毛病——盯着 Eyun开发文档 一个一个接口抠跑通一个 sendText 就觉得我会了。结果真上手做业务才发现单用一个接口能干的活儿特别有限。sendText 只能发消息getContactList 只能拉好友setCallback 只能收消息——单拎出来哪个都撑不起一个完整业务。真正让这些接口值钱的是把它们串起来用。我踩了十几个项目的坑慢慢总结出4种组合模式几乎覆盖了我做过的所有场景。这篇挨个讲每个都说清楚组合能力、实现逻辑、场景和踩过的坑。还有个误区得提一句组合不是越多接口越好。我见过有人把五六个接口全串进一个流程里结果中间任何一环出问题整条链都断排查起来要命。真正好用的组合通常是两三个接口配成一对简单又稳。模式一消息消息最经典的收→处理→回组合能力Webhook 回调 sendText/sendImage实现逻辑用户发消息进来 → 平台通过 Webhook 推到你服务 → 你处理后调 sendText 回回去。适用场景智能客服、自动问答、指令执行。举个例子用户在微信里发查订单Webhook 把这条消息推到你后端你查数据库拿到订单状态再调 sendText 把结果发回去。用户那头看到的就是秒回。踩坑我第一版没做消息去重平台因为网络波动重推了一次结果给用户连发了两条一模一样的回复被截图吐槽。后来用回调里的 msgId 做了幂等表Redis SETNX 一把锁重复推送直接丢。记住平台是至少推送一次不是只推一次。实现要点回调入口只做接收和入队业务处理丢异步队列里干回调响应控制在 1 秒内返回 code1000。响应慢了平台判定超时会重推越堆越多。模式二消息联系人先认人再回话组合能力Webhook 回调 getContactList sendText实现逻辑消息进来 → 先调 getContactList 拉联系人信息备注、标签→ 判断身份 → 个性化回复。适用场景VIP 客户识别、个性化回复、客户分级服务。举个例子客户发在吗你先查他的备注和标签发现是 VIP就优先回且话术更客气普通客户走标准话术。同一个在吗不同人收到不同的回复体验差很多。踩坑getContactList 别每来一条消息就全量拉一遍联系人多了能把你接口打爆。我现在的做法是缓存到本地TTL 设个十分钟标签变了再刷新。这块接口字段挺全可以对着 Eyun平台 上联系人管理的说明看别自己瞎猜字段名。实现要点getContactList 支持分页拉取第一次全量拉完建本地索引后续消息来了用 wxid 直接查缓存命中命中率能到九成以上。模式三事件消息好友变动自动触发组合能力好友变更回调 sendText/sendImage实现逻辑新好友添加、入群这类事件 → Webhook 推事件 → 你调 sendText 发欢迎消息。适用场景新好友欢迎、入群欢迎、流失预警。举个例子有人加你好友平台把好友变更事件推过来你立刻发一段欢迎语加产品介绍第一印象拉满。比人工一个个回效率高得多。踩坑欢迎消息别发太快也别太慢。太快容易被判定异常太慢用户都忘了加过你。我试出来 2-5 秒延迟比较稳。还有欢迎语里别带链接新好友第一条消息带链接风险高我栽过这跟头。实现要点好友变更事件不止 friendAdd 一种删好友、备注修改都有对应 event_type。删好友那个别浪费拿来做成流失预警客户一删你立刻通知销售跟进。模式四定时批量到点自动干活组合能力定时任务自己用 cron 或定时器 批量 sendText/sendFile实现逻辑到点触发 → 拉客户列表 → 循环调 sendText 批量发。适用场景日报推送、群发通知、定时提醒。举个例子每天早上 9 点自动拉一遍重点客户列表把昨晚生成的日报挨个发过去不用人盯着。踩坑批量发一定要加间隔我最早图快一秒发 20 条号当场被限。后来改成每条间隔 3-8 秒随机配合 Eyun开发文档 里说的频率建议稳了。另外 sendFile 发文件时确认文件 URL 是公网可访问的内网地址平台访问不到会发失败但不报错debug 半天。实现要点批量循环里每条单独 try-except一条失败不能中断整批。失败的记下来走补偿重试别跟成功条目混在一起不然重发时分不清谁该补谁不该补。怎么选这4种模式其实就看你的触发源是啥。触发源是用户发消息就走模式一或模式二——要不要认人就看业务需不需要分级。触发源是好友变动就走模式三事件驱动最自然。触发源是时间到点就走模式四定时批量最省事。复杂业务往往是几个模式叠加。我做的电商客服项目就是模式一模式二模式四混着用日常消息走模式一VIP 客户走模式二识别每天早上日报走模式四推。先把单个模式跑稳了再叠加别一上来就全堆上去。四种组合模式对比模式组合能力典型场景难度主要风险消息消息WebhooksendText智能客服低消息去重消息联系人WebhookgetContactListVIP 识别中联系人缓存事件消息事件回调sendText新好友欢迎中发送时机定时批量定时器批量 send日报推送中频率控制这张表是我做完几个项目倒推出来的新人照着选能少走弯路。难度都标在表里了但真正让你翻车的不是难度是那个主要风险列——每个模式我都在那上面吃过亏。模式三完整实现代码下面是模式三事件消息的完整实现Python 写的包含 Webhook 接收好友变更事件和自动发欢迎语import requests import time import threading import redis from flask import Flask, request, jsonify app Flask(__name__) r redis.Redis(decode_responsesTrue) BASE_URL https://api.eyunz.com # 以文档实际地址为准 AUTH_TOKEN eyk_your_auth # 别硬编码生产从配置中心读 W_ID 你的实例ID # 一个 wId 对应一个登录的微信 HEADERS { Authorization: fBearer {AUTH_TOKEN}, Content-Type: application/json } def send_welcome(wxid): 新好友添加后延迟3秒发欢迎语太快容易触发风控 time.sleep(3) payload {wId: W_ID, wcId: wxid, content: 你好呀感谢添加我是 XXX有问题随时说} resp requests.post(f{BASE_URL}/sendText, jsonpayload, headersHEADERS, timeout10) data resp.json() if data.get(code) ! 1000: print(f欢迎消息发送失败: {data}) app.route(/webhook, methods[POST]) def webhook(): data request.json event_type data.get(eventType) # 好友变更事件平台推送的 JSON 里带事件类型 if event_type friendAdd: wxid data.get(wxid) msg_id data.get(msgId) # 事件也要幂等防止平台重推导致重复发欢迎语 if msg_id and not r.set(fevt:{msg_id}, 1, nxTrue, ex600): return jsonify({code: 1000}) threading.Thread(targetsend_welcome, args(wxid,)).start() # 回调必须快速返回否则平台判定超时会重推 return jsonify({code: 1000, message: success}) if __name__ __main__: app.run(port8080)几个点说一下wId 是实例 ID一个 wId 对应一个登录的微信Auth 放请求头里做鉴权别塞 body 里Webhook 回调必须秒回重活丢线程或消息队列里干事件回调也要做幂等不然平台重推你会给新好友发两条欢迎语那场面挺尴尬的。最后组合这事儿没有标准答案4 种模式也不是非此即彼实际项目里往往是混着用——比如客服场景里既有消息消息又带消息联系人。关键是先把每个单接口摸熟再考虑怎么串。想看每个接口具体参数和返回字段的直接翻 Eyun开发文档比我这篇全多了。接口组合这事做多了就有手感第一次串肯定会卡把卡住的地方记下来下次就顺了。