企业官网建设流程全解析

做微信自动化这两年，我前后经手了十几个项目。最开始接的时候，我犯了大多数新手都会犯的毛病——盯着 Eyun开发文档 一个一个接口抠，跑通一个 sendText 就觉得"我会了"。

结果真上手做业务才发现：单用一个接口，能干的活儿特别有限。sendText 只能发消息，getContactList 只能拉好友，setCallback 只能收消息——单拎出来哪个都撑不起一个完整业务。

真正让这些接口"值钱"的，是把它们串起来用。我踩了十几个项目的坑，慢慢总结出4种组合模式，几乎覆盖了我做过的所有场景。这篇挨个讲，每个都说清楚组合能力、实现逻辑、场景和踩过的坑。

还有个误区得提一句：组合不是越多接口越好。我见过有人把五六个接口全串进一个流程里，结果中间任何一环出问题整条链都断，排查起来要命。真正好用的组合，通常是两三个接口配成一对，简单又稳。

模式一：消息+消息，最经典的"收→处理→回"

组合能力：Webhook 回调 + sendText/sendImage

实现逻辑：用户发消息进来 → 平台通过 Webhook 推到你服务 → 你处理后调 sendText 回回去。

适用场景：智能客服、自动问答、指令执行。

举个例子：用户在微信里发"查订单"，Webhook 把这条消息推到你后端，你查数据库拿到订单状态，再调 sendText 把结果发回去。用户那头看到的就是"秒回"。

踩坑：我第一版没做消息去重，平台因为网络波动重推了一次，结果给用户连发了两条一模一样的回复，被截图吐槽。后来用回调里的 msgId 做了幂等表，Redis SETNX 一把锁，重复推送直接丢。记住平台是"至少推送一次"，不是"只推一次"。

实现要点：回调入口只做接收和入队，业务处理丢异步队列里干，回调响应控制在 1 秒内返回 code=1000。响应慢了平台判定超时会重推，越堆越多。

模式二：消息+联系人，先认人再回话

组合能力：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 客户走模式二识别，每天早上日报走模式四推。先把单个模式跑稳了再叠加，别一上来就全堆上去。

四种组合模式对比

这张表是我做完几个项目倒推出来的，新人照着选能少走弯路。难度都标在表里了，但真正让你翻车的不是难度，是那个"主要风险"列——每个模式我都在那上面吃过亏。

模式三完整实现代码

下面是模式三（事件+消息）的完整实现，Python 写的，包含 Webhook 接收好友变更事件和自动发欢迎语：

import requests import time import threading import redis from flask import Flask, request, jsonify app = Flask(__name__) r = redis.Redis(decode_responses=True) BASE_URL = "https://api.eyunz.com" # 以文档实际地址为准 AUTH_TOKEN = "eyk_your_auth" # 别硬编码，生产从配置中心读 W_ID = "你的实例ID" # 一个 wId 对应一个登录的微信 HEADERS = { "Authorization": f"Bearer {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", json=payload, headers=HEADERS, timeout=10) 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(f"evt:{msg_id}", "1", nx=True, ex=600): return jsonify({"code": "1000"}) threading.Thread(target=send_welcome, args=(wxid,)).start() # 回调必须快速返回，否则平台判定超时会重推 return jsonify({"code": "1000", "message": "success"}) if __name__ == "__main__": app.run(port=8080)

几个点说一下：wId 是实例 ID，一个 wId 对应一个登录的微信；Auth 放请求头里做鉴权，别塞 body 里；Webhook 回调必须秒回，重活丢线程或消息队列里干；事件回调也要做幂等，不然平台重推你会给新好友发两条欢迎语，那场面挺尴尬的。

最后

组合这事儿没有标准答案，4 种模式也不是非此即彼，实际项目里往往是混着用——比如客服场景里既有消息+消息，又带消息+联系人。关键是先把每个单接口摸熟，再考虑怎么串。想看每个接口具体参数和返回字段的，直接翻 Eyun开发文档，比我这篇全多了。

接口组合这事做多了就有手感，第一次串肯定会卡，把卡住的地方记下来，下次就顺了。