在完成了 ChatID 的同步后，下一步的关键是建立一套高效的数据模型，将企业微信的ChatID与我们业务系统的客户标签、产品线、生命周期阶段等属性关联起来，这是实现精准群发目标筛选的基础。
1. 映射模型的必要性
企业微信 API 只提供群聊 ID 和群名，但我们的业务需求往往是：
按产品筛选：向所有购买了“产品线 A”的客户群发送更新通知。
按等级筛选：仅向“VIP 客户群”发送特殊活动消息。
按状态筛选：找出所有处于“试用期”的群聊进行引导。
如果每次筛选都依赖复杂的实时计算，将严重拖慢群发任务的启动速度。因此，需要预先建立索引化的映射关系。
2. 核心数据表结构设计
我们采用三表关联模型（多对多关系）来实现灵活且高效的映射：
表 A: 外部群聊主表 (WeCom_Chat_Group)
存储从企业微信同步来的群聊基础信息。
| 字段名称 | 数据类型 | 索引 | 作用描述 |
id | VARCHAR(64) | 主键 (PRIMARY KEY) | ChatID，群聊唯一标识。 |
owner_userid | VARCHAR(32) | 索引 | 群主的企业微信 UserID。 |
group_name | VARCHAR(128) | 无 | 群聊名称。 |
status | TINYINT | 索引 | 群聊状态 (1: 正常, 0: 已解散)。 |
表 B: 内部业务标签表 (Internal_Business_Tag)
存储所有业务筛选所需的标签定义。
| 字段名称 | 数据类型 | 索引 | 作用描述 |
tag_id | INT | 主键 (PRIMARY KEY) | 业务标签的内部唯一 ID (例如 101)。 |
tag_name | VARCHAR(64) | 唯一索引 (UNIQUE) | 标签名称 (例如：“产品线 A”、“续费预警客户”)。 |
tag_type | VARCHAR(32) | 索引 | 标签类型（例如：“产品线”、“客户等级”）。 |
表 C: 群聊与标签关系映射表 (Chat_Tag_Mapping)
作为桥梁表，实现ChatID和TagID的多对多关联，是查询效率的关键。
| 字段名称 | 数据类型 | 索引 | 作用描述 |
chat_id | VARCHAR(64) | 复合索引 | 关联到 表 A 的外键。 |
tag_id | INT | 复合索引 | 关联到 表 B 的外键。 |
mapping_id | BIGINT | 主键 | 记录自身的唯一 ID。 |
高性能关键：必须在
(chat_id, tag_id)字段上创建复合唯一索引。这使得通过标签 ID 查找对应的群聊 ID 时，数据库可以直接通过索引快速定位，极大提升筛选速度。
3. 高效筛选查询示例
通过利用Chat_Tag_Mapping表的索引进行 JOIN 查询，可以实现毫秒级的目标群聊筛选。
场景示例：找出所有同时带有“产品线 A”和“VIP 客户”标签的 ChatID。
SELECT T1.chat_id FROM Chat_Tag_Mapping T1 JOIN Internal_Business_Tag T2 ON T1.tag_id = T2.tag_id WHERE T2.tag_name IN ('产品线 A', 'VIP 客户') GROUP BY T1.chat_id HAVING COUNT(DISTINCT T2.tag_name) = 2; -- 确保该群聊同时满足所有两个标签的条件4. 数据维护与同步逻辑
这种映射关系需要持续维护，以保证实时性：
数据源驱动：当业务系统中的客户标签、产品线关系发生变化时，应通过内部事件触发
Chat_Tag_Mapping表的异步更新。定期校验：尽管依赖事件驱动，仍需定期（例如每周一次）通过全量校验逻辑来修复可能存在的脏数据或遗漏的映射关系。
通过这种模型，我们彻底解耦了企业微信的外部 ID 和内部业务逻辑，为后续的高性能群发奠定了坚实的数据基础。
QiWe开放平台提供了后台直登功能，登录成功后获取相关参数，快速Apifox在线测试，所有登录功能都是基于QiWe平台API自定义开发。
