Workerman原生不支持group/tag，需手动维护$group_con_map或用GatewayWorker::joinGroup；推荐后者，因其跨进程、可持久且自动清理；tag需结合Redis与bindUid模拟。
Workerman 本身不提供原生的 group 或 tag 概念，所有分组逻辑必须由开发者自己维护映射关系。直接用数组存连接、靠 Channel 广播或走 GatewayWorker 的 joinGroup 才是实际可行路径。
用 $group_con_map 手动维护分组映射（纯 Worker 场景）
这是最轻量、也最容易出错的方式：在内存中用全局数组记录每个群组 ID 对应的连接对象列表。
-
$group_con_map['room_101'][$connection->id] = $connection是典型写法，注意必须用$connection->id作键，不能用引用或对象本身，否则 PHP 序列化/跨进程时失效 - 每次
onMessage收到{"cmd":"join","group_id":"room_101"}，就往对应数组里塞；onClose时必须遍历$connection->joined_groups（需你自己存）并unset，否则内存泄漏 - 跨 Worker 进程不生效——
$worker->count = 4时，四个进程各自维护一份$group_con_map，发消息只能触达本进程内的连接 - 若要跨进程广播，必须引入
Channel\Server，调用Channel\Client::publish('send_to_group', [...])，再在onWorkerStart里监听该事件并投递消息
用 GatewayWorker::joinGroup 实现真正分组（推荐方案）
GatewayWorker 封装了底层细节，joinGroup 是唯一被设计为“可跨机器、可持久、可清理”的分组接口，底层自动处理连接迁移、进程重启、多机部署等边界情况。
- 客户端连接成功后，Gateway 会通过
onConnect回调返回$client_id，你必须立刻用Gateway::joinGroup($client_id, 'room_101')加入分组，不能延迟或丢弃 - 同一个
$client_id可多次调用joinGroup加入多个 group，也会自动去重；调用leaveGroup($client_id, 'room_101')可退出 - 发送时直接
Gateway::sendToGroup('room_101', $message)，无需关心连接在哪台机器、哪个进程，Gateway 内部通过GatewayClient和Register服务协调 - 注意：Gateway 不处理业务逻辑，
joinGroup必须由你的 MVC 后端（如 ThinkPHP 的 bind.php）触发，而不是前端直接连 Gateway 发指令
Tag 不是 Gateway 的原生能力，得靠 uid + 自定义字段模拟
Gateway 没有 tag 接口，但你可以把 tag 当作用户属性存在 Redis，再结合 bindUid 关联到连接，实现“按标签筛选推送”。
- 例如：用户 A 的 uid=123，打上 tag
["vip", "ios"]，存入 Redis：hset user:123 tags "vip,ios" - 推送前先查 Redis：
hget user:123 tags，筛出含vip的 uid 列表，再用Gateway::sendToUid逐个发 - 不要试图在
$connection上挂$connection->tags = [...]——Worker 进程重启后丢失，且无法跨进程共享 - 如果 tag 变更频繁（如实时权限开关），建议用 Redis Pub/Sub 订阅变更事件，在 Gateway 的
onWorkerStart里监听并刷新本地缓存，避免每次推送都查 Redis
真正的难点不在怎么加 group，而在于谁负责清理、谁负责同步、谁保证不重复加入。手动维护 $group_con_map 看似简单，但上线后第一个凌晨三点的内存泄漏报警，大概率就来自 onClose 里漏掉了一行 unset。
