企业官网建设流程全解析

微信数据（消息/好友/群）和业务数据（订单/用户/工单）如果各存各的，分析和管理都会割裂。统一数据管理的核心是 3 个统一：统一标识、统一存储、统一同步。下面逐个拆解怎么落地。

一、统一标识：微信 wxid 与业务 userId 建立映射

统一方式：建映射表（wxid↔userId）→ Webhook 回调的 fromUser 通过映射表转成 userId → 业务数据全部用 userId 关联。

按照 Eyun 开发文档 的回调规范，Webhook 回调 JSON 中 fromUser 是对方的 wxid。新好友通过 Webhook 好友事件回调自动写入映射表，历史好友通过联系人同步接口批量补齐。关键技术点：映射表加唯一索引防止重复绑定，msgId 去重防止同一事件重复入库。

大白话：先把"微信的人"和"系统的人"对上号，后面所有数据都挂在 userId 下，微信数据和业务数据就串起来了。

二、统一存储：微信数据和业务数据进同一个数据库体系

存储方式：微信消息表（msgId、wxid、userId、content、时间戳）、好友表（wxid、userId、备注、标签）、群表（群ID、群名、成员数）与业务表（订单表、工单表）同库或同数据仓库 → 通过 userId 关联查询。

Eyun 的消息记录接口拉取的历史消息按此结构入库，群消息和群信息也按同样方式落表。这样一条 JOIN 就能把"这个人聊过什么"和"这个人下过什么单"连起来。

大白话：微信的聊天记录、好友列表和你的订单数据放一起，用一个 userId 就能查到完整链路。

三、统一同步：微信数据实时 + 定时同步到统一存储

同步方式：实时同步走 Eyun Webhook 回调（新消息/新好友立刻入库）、定时同步走 Eyun 的消息记录接口和联系人同步接口（补偿拉取防遗漏）。

按照 Eyun 开发文档的规范，定时拉取用增量游标避免全量，用 msgId 或时间戳做游标，拉到哪记到哪。Eyun API 的 Webhook 回调和拉取接口配合，实现"实时不丢 + 定时兜底"。

大白话：新数据实时进（Webhook 推），历史数据定期补（接口拉），双保险确保数据不缺。

3个要素对比

3要素统一数据管理框架代码

# 要素1：统一标识——wxid 与 userId 映射 def resolve_user(fromUser): # Webhook 回调里的 wxid return db.get("SELECT userId FROM wx_user_map WHERE wxid=%s", fromUser) # 要素2：统一存储——微信消息与业务数据同库，按 userId 关联 def save_msg(event): userId = resolve_user(event["fromUser"]) db.exec("INSERT INTO wx_msg(msgId,wxid,userId,content,ts) VALUES (%s,%s,%s,%s,%s)", (event["msgId"], event["fromUser"], userId, event["content"], event["timestamp"])) # 要素3：统一同步——Webhook 实时进 + 定时增量拉取兜底 def on_webhook(event): save_msg(event) # 实时：新消息立刻入库 def cron_sync(cursor): # 定时：增量游标补偿拉取 for msg in eyun.fetch_msg_records(cursor): save_msg(msg) db.set("sync_cursor", msg["msgId"]) # 记录游标，下次接着拉

结尾

3 个要素按顺序建设——先统一标识（没有映射，数据是孤岛），再统一存储（有了标识才能同库关联），最后统一同步（有了存储结构才能定同步策略）。统一后的典型收益：一条 SQL 就能查"某个微信好友的历史消息 + 订单记录 + 工单记录"，支撑客服、运营、分析的完整数据视图。落地建议：映射表先在小范围验证准确性，再放开全量同步，避免脏数据污染业务表。数据拉取接口的参数详见 Eyun 开发文档，在 Eyun 平台 开通 wId 后即可开始同步。