做个人微信二次开发绕不开一个基础问题微信里的 wxid 和你业务系统里的用户 ID怎么对应起来。这个问题不先想清楚后面收消息、发消息、用户管理都会乱套。Eyun API 提供了 wxid 这个微信侧标识业务系统要做的是在它和自己的 userId 之间搭一套 3 层身份映射。下面直接讲设计思路。一、微信侧标识层wxid 是微信世界的身份证号wxid 是微信给每个用户分配的唯一标识形如wxid_abc123Eyun 的接口全部围绕它操作收消息Webhook 回调的 JSON 里fromUser字段就是发消息对方的 wxid发消息按照 Eyun 开发文档 的规范sendText 需要传 wId、toUser、content 三个必填参数其中 toUser 填的就是目标用户的 wxid。大白话给谁发消息就得拿到谁的 wxid。wxid 不用你生成微信分配好了Eyun 的回调会原样推过来存下来就行。二、业务侧标识层userId 是业务世界的工牌号你的业务系统有一张用户表每个用户有自己的主键比如 userId1001 对应张三。这套体系是你自己定的跟微信无关。麻烦在于同一个人在你系统里是 userId1001在微信里是 wxid_xxx两套体系各说各话。订单、积分、消息统计都基于 userId但消息进来只带 wxid——所以必须打通。三、映射关系层一张表把两个世界绑起来打通方式很简单建一张映射表字段不用多字段说明id主键自增wxid微信侧标识唯一索引user_id业务侧用户主键bind_time绑定时间status绑定状态1 有效 / 0 解绑绑定时机是新好友事件Webhook 推送新好友回调 → 从 JSON 里取fromUser即 wxid→ 查映射表看是否已绑定 → 未绑定则创建映射记录。在 Eyun 平台 管理的 wId 对应的通讯录里每个联系人的 wxid 都是唯一的映射一一对应不会出现一个 wxid 挂两个 userId 的情况。绑定完成后Webhook 收到的每条消息都能通过 wxid 反查到 userId业务逻辑就知道该处理谁的数据。四、3 层映射对比映射层标识来源存储方式大白话微信侧标识层wxid微信分配Webhook 回调携带随消息记录存储微信世界的身份证号业务侧标识层userId业务系统用户表主键业务用户表你系统里的工牌号映射关系层wxid↔userId新好友事件触发绑定独立映射表一张表记录谁是谁五、代码3 层身份映射框架def get_or_create_user(wxid: str) - int: wxid → 映射表 → userId 的查询与绑定 row db.query(SELECT user_id FROM wx_user_map WHERE wxid%s AND status1, wxid) if row: # 已绑定直接返回业务侧标识 return row[user_id] user_id db.insert( # 未绑定创建业务用户 INSERT INTO users(name) VALUES (%s), fwx_{wxid[-6:]}) db.execute( # 写入映射层 INSERT INTO wx_user_map(wxid,user_id,bind_time,status) VALUES (%s,%s,NOW(),1), (wxid, user_id)) return user_id def on_message(callback: dict): # Webhook 消息回调入口 user_id get_or_create_user(callback[fromUser]) # fromUser 即 wxid save_message(user_id, callback[content]) # 定位到业务用户后处理写在最后3 层映射就是身份体系的完整设计微信侧用 wxidEyun 接口的操作标识业务侧用 userId业务系统用户主键中间用映射表绑定。映射建好后收消息能定位到人sendText 发送时也能从 userId 反查 wxid双向都通。身份体系是消息处理、用户管理、数据分析的共同基础建议项目启动时就把表结构和绑定流程定下来别等业务跑起来再返工。wId 和回调 JSON 中 wxid 字段的详细说明见 Eyun 开发文档。