官网友情链接 wechatapi.net个人微信二次开发刚开始时很多系统会直接拿某个微信侧标识当作客户主键。一个账号下的好友列表中出现一个联系人就创建一条customer。这种方式开发快但系统进入多账号以后很快会遇到问题。同一个真实客户可能添加销售A添加客服B存在于多个微信群重新删除再添加。如果每一条微信关系都被当成一个客户主体CRM会产生大量重复客户。所以个人微信API接入以后需要明确区分平台联系人ID微信关系ID客户主体ID。WechatApi 可以作为个人微信API接入层把不同账号下的联系人、好友关系和消息带入本地系统。本地客户中心则为真实客户创建稳定customer_id再让多条微信关系指向同一主体。一、为什么 account_id contact_id 不能直接当客户主体它最多能唯一表示某个账号下的一条微信关系。不能表示真实客户。同一个人添加另一个账号就会产生新的组合。二、一个具体例子客户王先生账号A下 relation R1。账号B下 relation R2。CRM里只有客户 C100。正确模型R1 → C100。R2 → C100。而不是R1C100R2C200。三、稳定主键应该由本地生成customer_id使用UUID/雪花ID等本地稳定ID。不要依赖昵称、手机号或微信展示字段直接当主键。这些业务字段都可能变化。四、WechatApi 在这里的位置WechatApi负责账号联系人消息群成员。本地客户中心负责真实主体ID。五、relationship_id也要稳定每个账号与客户的关系独立保存relation_id。关系删除后不要物理删除。状态inactive。重新添加可以产生新周期。六、群成员关系再次独立membership_id。群成员指向contact/relation/customer。不要让group_member直接等于customer。层级清晰。七、CRM映射customer_id ↔ crm_customer_id。CRM客户ID也不应该直接成为本地主键。因为未来可能切CRM或重新合并。映射层更灵活。八、手机号只是匹配信号手机号很强。但仍然不是主键。手机号可能变更。主键不能跟着变化。九、客户合并C100、C200确认同一人。保留C200.merged_intoC100。旧ID仍然可以重定向。不要物理消失。十、客户拆分误合并后需要拆。如果所有业务都直接依赖关系ID和来源恢复更容易。这就是主键设计的重要性。十一、搜索使用业务字段用户不需要记customer_id。可以搜昵称备注手机号公司。主键只服务系统稳定关联。十二、消息关联消息尽量记录relation_idconversation_id。customer_id可以作为冗余查询字段但来源关系保留。以后主体纠错更容易。十三、任务和工单业务对象引用customer_id。同时保存source_relation。知道客户通过哪个微信关系触发。十四、数据迁移未来账号关系重新导入。稳定customer_id让CRM、工单不需要重建。只重新绑定relation。十五、权限客户主体统一以后。仍然按relation owner和业务负责人计算权限。统一主体不等于所有员工共享客户。十六、数据看板真实客户数微信关系数平均每客户关系数重复候选合并。数据会比“好友总数”更加真实。十七、异常一个relation同时指向两个customer。属于严重数据异常。数据库层最好限制。十八、总结个人微信二次开发中的ID设计看起来很底层但它会直接决定未来客户去重、CRM、群成员、工单和多账号能不能长期稳定。WechatApi 可以把不同微信账号的联系人和群关系持续接入系统。本地客户中心则用稳定customer_id表示真实客户用relation_id表示具体微信关系用membership_id表示群成员关系。只有主体和关系彻底分开一个客户在多个账号、多个群、删除重加以后整个业务系统仍然能认出“这还是同一个人”。这也是个人微信API系统从单账号工具走向长期客户资产管理必须先做对的底层设计。