爱串门的老王最近这段时间一直在折腾用 Flutter 开发 OpenHarmony 平台上的剧本杀组队 App，项目推进到中期有个模块差点把我心态搞崩——就是等级特权系统。很多做工具类 App 的人会把等级特权当成一个小功能，无非就是一张表存等级、前端显示进度条、高了给个徽章。真做进剧本杀这种强社交、强组队场景里，你会发现它牵扯到经验计算、权限校验、组队权重、结算快照、跨端展示甚至设备特性适配，任何一个环节偷懒都会在线上爆雷。
这篇文章我完整梳理一下这套等级特权系统的实现过程，包括成长规则设计、特权码表、组队场景联动、服务端鉴权，以及 Flutter 在 OpenHarmony 设备上的真实兼容问题。项目本身是面向城市剧本杀玩家的组队工具，主要功能是建房间、拉队友、分角色、约局，后期还加了车队信用、局后评价和金币激励。等级特权系统是贯穿整个产品的核心付费与留存抓手，适合用 Flutter 做跨端、并计划适配 OpenHarmony 的团队参考。
1. 项目背景与等级特权系统的整体设计思路
1.1 为什么剧本杀组队App需要一套等级特权系统
剧本杀跟普通手游不一样，一局动辄三四小时，组队门槛天然偏高。玩家打开 App 的核心诉求是快速找到愿意一起拼本的人，而不是单纯刷时长。这时候如果没有用户分层，老玩家和新玩家混在一起，很容易出现老带新耐心耗尽、新人找不到组织的恶性循环。
我设计这套等级特权系统的目标有三个：第一，通过经验值和等级把玩家的活跃行为沉淀下来；第二，用等级解锁特权，让高频用户获得实实在在的组队便利；第三，通过带队、开房间、完成剧本等行为引导玩家从“参与者”变成“组织者”。这个思路跟大多数社区产品的成长体系类似，但剧本杀的特点是班级感强，一个车队固定成员之间信任成本很高，所以特权设计必须围绕组队效率，而不是单纯的无脑折扣。
另一个原因是商业化压力。剧本杀 App 做纯工具很难赚钱，但如果等级特权系统后面能接入金币购买、房主道具、局后礼物，整个产品的商业闭环就有抓手。所以我把等级特权系统放在中台层面来做，后续任何新业务都能复用这一套能力。
1.2 跨端框架选型：Flutter for OpenHarmony这条路到底行不行
项目立项时最纠结的就是跨端方案。团队既不想 Android 和 iOS 各写一套，又看到 OpenHarmony 设备量在快速增长，希望尽早覆盖。最后选了 Flutter for OpenHarmony，也就是通过开源社区维护的 Flutter 适配层，把 Flutter 引擎跑在 OpenHarmony 上。这样做的好处很明显：Dart 层业务代码几乎可以完全复用，UI 用同一套 Widget，底层少量平台通道做差异化适配。
实测下来这条路是能走通的，但坑也不少。Flutter 官方对 OpenHarmony 的支持并不是默认主线，需要把 Flutter SDK 切换到特定分支，然后手动编译引擎包。版本对齐要特别注意，比如 3.22 版本的适配分支跟 OpenHarmony API 12 的表现和 API 13 的设备差异就很大。因为等级特权系统要频繁操作本地缓存和系统通知，我接触的第一批天坑基本都是插件包不可用，后面单独开了一章讲。
从架构角度，Flutter 负责 UI 和大部分业务逻辑，OpenHarmony 侧只做原始能力提供。特权系统里涉及的用户等级计算、权益判断全部放服务端，客户端只做展示和局部控制。这样即使某天底层从 Flutter 换成原生的鸿蒙 ArkUI，后端逻辑也不用动。
1.3 等级特权系统的核心模块划分
我把整个系统拆成三层：
第一层是成长引擎，负责经验值采集、升级判定、等级快照。这一层我放在服务端做，主要原因是防作弊。客户端上报经验事件只能作为参考，最终结算必须由服务端统一计算。第二层是特权引擎，维护一份特权码表，每个特权关联等级门槛、适用范围和生效配置，服务端在进行任何核心操作时都会先做权限校验。第三层是展示与提示层，在 Flutter 端渲染等级进度、特权列表、解锁弹窗，以及组队房间界面里的特权标识。
这个拆法参照了 RBAC 权限模型的思路。一个用户可以拥有多个特权，一个特权对应多个功能点，功能点再对应到前后端具体操作。不能把等级和特权直接写在 if else 条件里，否则等特权数量超过 20 个，代码会彻底失控。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 等级成长的数据模型与经验值计算规则
2.1 经验值埋点与上报策略
经验值来源我做了充分调研，不能只按登录天数给分，那样大家会变成纯粹的签到机器。最终我确定了几类经验事件，如下表所示：
| 经验事件 | 经验值 | 每日上限次数 | 设计目的 |
|---|---|---|---|
| 每日签到 | 10 | 1 | 拉日活 |
| 发布组队房间 | 30 | 3 | 刺激供给 |
| 成功组队并完成剧本 | 80 | 2 | 核心行为 |
| 担任 DM 带队 | 120 | 1 | 培养组织者 |
| 完成局后评价 | 20 | 5 | 积累剧本口碑 |
客户端通过埋点事件把经验行为上报，但服务端并不是收到事件就立刻加经验。我采用了一种宽松但可校验的设计：客户端上报后，服务端写经验流水，等级计算在每日凌晨和关键行为结算时触发。这样做的好处是避免用户一局游戏刚结束就反复刷新看到等级变化，减少阶段式强迫感。同时也能把高并发写入分摊到不同时间点。
注意，服务端必须做次数校验。比如组队完成的经验，客户端可能因为重试重复上报，服务端必须根据行为幂等键（比如游戏局 ID）去重，否则玩家可以靠断网重试刷经验。我刚开始漏了这层，测试阶段就发现同一个剧本局被加了三次经验。
2.2 升级曲线设计：为什么不能用简单的线性累加
很多新手设计等级的时候喜