企业微信二次开发：标签怎么批量打？客户自动分群，运营不再手工贴

标签体系的两套边界（企业标签和个人标签）和那个覆盖式的坑，之前专门写过——更新前必须先拉现有标签合并。但"知道坑"和"批量作业怎么跑"是两回事：几百上千个客户要打标，手工在后台点是不现实的。这篇讲批量打标的工程实现：任务怎么切、合并怎么做、事件回环怎么防。

批量打标的三步流水线

一次批量打标任务的标准流程：圈人 → 取现状 → 合并写入。

圈人：确定目标客户集合。来源通常是业务规则（"7天内下单的"）或数据同步结果，圈人结果落任务表，别在内存里圈——任务要可恢复、可重跑，就必须先落库：

CREATE TABLE label_task (
id BIGINT PRIMARY KEY,
rule_name VARCHAR(64) NOT NULL,
ext_user_id BIGINT NOT NULL,
label_ids JSON NOT NULL, — 本任务要打的标签
status VARCHAR(16) DEFAULT 'pending', — pending/done/failed
created_at DATETIME,
KEY idx_status (status, id)
);

取现状：逐个客户拉当前已打标签。这一步就是防覆盖的关键——标签更新接口是覆盖式，直接把新标签写进去会把客户身上已有的标签全部抹掉。

合并写入：现有标签 ∪ 本次标签，去重后写入。合并逻辑一行集合运算，但它是整个流水线的灵魂，漏了它就是事故。

分批与限速：别一口气全打

几千个客户逐个写标签，发送频率不低，直接裸跑大概率撞频控。流水线的消费者要限速：每秒固定 N 条，失败进重试队列（指数退避），连续失败的任务标 failed 等人工看。任务表的状态机保证重跑幂等——服务重启后从 pending 继续，已 done 的不重复处理。

事件回环：label_change 的防循环设计

打完标签，平台会推 label_change 事件（客户标签变更通知）。这个事件在架构里有两个用途和一个大坑：

用途一：数据回写。收到事件后更新本地客户标签快照，保证本地数据与平台一致，不用再主动反查。

用途二：触发下游动作。"打了'高意向'标签的客户进培育队列"这类分群逻辑，订阅事件比轮询库优雅得多。

大坑：循环打标。如果你的分群逻辑是"收到 label_change → 查客户 → 又给他打了个标签"，恭喜，你造出了永动机——A 标签触发打 B 标签，B 的事件又触发打 A。防法很简单也很硬：事件处理器里只读不写。所有打标动作只允许从业务流水线发起，事件订阅者一律不做写标签操作，从架构上掐断循环的可能。

客户自动分群：标签组合即分群

标签打准之后，分群就只是查询条件："标签含 A 且不含 B"的一行 SQL 就是一个群。运营要新分群时，给规则不给手工名单——规则是活的，新客户打上标签自动入群；手工名单是死的，第二天就过期了。

分群结果的去向：发通知时按群圈人（精确触达）、客户群拉人时按群选源（群成员质量可控）。这两个动作的接口细节在 Eyun 开发文档可查，标签字段的说明也在同一处。

落地自查清单

检查项

标准

Eyun 官网上有标签能力的整体介绍，配合文档食用更顺。批量打标的本质是把"运营的手工动作"翻译成"工程的可重跑流水线"——标签打得准、打得快，后面的分层运营才有地基，而那一个防循环的设计决策，能帮你省掉一次凌晨排查永动机的时间。