Q47: 如何设计公会系统？

核心结论

公会系统不是一个“大号好友群”，而是“长期组织关系加权限体系加共享资产”的组合系统。

真正需要优先设计的不是 UI，而是：

• 成员关系和职位权限
• 申请、邀请、退出、踢出流程
• 公会公共资产和日志
• 跨服、离线和在线状态同步

只要公会仓库、福利、活动这些功能一接进来，它就已经变成一个高价值组织系统。

一、公会系统的核心职责

通常包括：

• 组织成员
• 管理职位和权限
• 支持公告、聊天、申请、邀请
• 承载公会科技、仓库、活动、战斗等扩展功能

所以公会系统的底座不是聊天，而是“组织状态管理”。

二、先把“组织关系”和“在线互动”分开

1. 组织关系

更偏静态：

• 公会主档
• 成员归属
• 职位
• 公告
• 贡献

2. 在线互动

更偏动态：

• 在线成员
• 公会聊天
• 实时通知
• 活动报名

这两部分访问模式完全不同，不应该混成一套简单结构。

三、权限体系必须先设计

公会系统最容易失控的点是“谁能做什么”。

至少要明确定义：

• 会长权限
• 副会长权限
• 官员权限
• 普通成员权限

尤其是这些高风险操作：

• 踢人
• 转让会长
• 使用仓库
• 修改公告
• 发放公会福利

如果权限只在前端控制，迟早会出问题。

四、公会公共资产要单独看待

一旦有：

• 公会仓库
• 公会资金
• 公会科技资源
• 领地收益

这些都不能再当成普通社交功能处理。

它们需要：

• 更严格的权限控制
• 变更流水
• 可审计日志

因为这是多人共享资产，风险比个人背包更大。

五、成员变更流程为什么要严谨

公会系统典型高频流程包括：

• 申请加入
• 邀请加入
• 退出公会
• 踢出成员
• 转让职位

这些流程看似简单，但都涉及：

• 权限判断
• 状态变更
• 通知和日志
• 其他系统联动

例如成员退出后，可能还要处理：

• 公会任务资格
• 公会战报名状态
• 仓库权限回收

六、在线状态和公会广播要控制成本

人数一多后，公会系统很容易变成广播热点。

例如：

• 一人上线，所有成员收到提示
• 一条公告修改，全员刷新
• 成员列表频繁全量同步

更稳妥的做法通常是：

• 进入公会界面时拉摘要
• 在线状态做增量同步
• 聊天和成员列表分通道处理

七、跨服和大区体系会显著提高复杂度

如果有跨服公会、公会战、公会排行榜，就要解决：

• 成员 ID 全局唯一
• 跨服在线状态
• 组织数据统一存放
• 活动服与主服之间的数据同步

这时公会系统通常已经不是单服附属模块，而更接近社交与组织中台。

八、工程上更稳妥的设计

常见做法是：

• 公会主档独立存储
• 成员关系表独立存储
• 在线状态从会话层读取
• 公会公共资产保留审计流水
• 公会聊天、通知、活动分别拆子模块

这样后面扩展功能时不会把核心组织关系拖乱。

九、常见误区

1. 公会系统就是好友系统加群聊

远远不够。组织权限和共享资产才是核心复杂度来源。

2. 职位只是一个展示字段

不对。职位本质上决定操作权限和责任边界。

3. 公会仓库和个人背包逻辑差不多

不对。公会仓库涉及多人共享资产，审计要求更高。

参考资料

• 各类在线游戏公会、组织权限与共享资产实践资料