半张老头最近团队接了一个剧本杀门店的线上组队需求，要求App必须能在OpenHarmony设备上稳定跑起来，同时还要用Flutter跨Android和iOS，这就把技术选型卡在了一个特别的交叉点上。整个开发周期里，最花心思的不是组队匹配本身，而是围绕用户留存做的等级特权系统——这个东西表面看是一套积分规则，实际落地时涉及数据结构设计、客户端状态管理、跨端兼容和OpenHarmony平台适配，坑点相当密集。这篇就把整个实现过程拆开讲清楚，从系统设计到代码实现再到排坑实录，适合正在做Flutter跨端、或者准备在OpenHarmony上落地应用的开发者参考。
1. 项目定位与技术选型：为什么在OpenHarmony上用Flutter做剧本杀组队
1.1 剧本杀组队的业务场景与等级系统价值
剧本杀门店的线上组队场景，本质上是一个同城LBS社交加预约的组合：用户浏览剧本、查看场次、发起组队、凑齐队友后到店体验。和普通社交App不太一样，剧本杀的组队有三个特点：一是决策链路长，一个人选本往往要参考队友评价；二是熟人复购率高，同一个车队会反复约场；三是时段集中，周末晚场的组队爆发力非常强。
等级特权系统在这类产品里的定位，不是简单的积分商城，而是整个留存体系的中枢。用户通过组队、到店、评价、分享获得经验值，经验值推高等级，等级解锁对应特权，比如优先匹配场次、剧本折扣、专属头像框。这样一来，用户每一次组队行为都被转化为长期资产，车队队长也有动力持续拉新，门店端则能靠等级数据做精准运营。
从技术视角看，等级特权系统牵扯到三个核心问题：等级规则怎么配置、用户数据怎么存储、特权能力怎么和业务解耦。这三个问题如果在客户端硬编码，后期运营改一条规则就要发版，所以我一开始就定下了“配置下发、本地缓存、权限统一校验”的架构基调。
1.2 Flutter for OpenHarmony的选型权衡
选择Flutter而不是ArkTS原生开发，核心原因有两个。第一是团队现有代码资产，Android和iOS端的Flutter业务代码已经跑了一年多，剧本杀App是新增场景，复用现有Flutter基建能省掉三端分别开发的成本。第二是Flutter自绘引擎的UI一致性，OpenHarmony的ArkUI虽然能力不弱，但毕竟和Flutter的组件模型不一样，跨端复用同一个UI逻辑更高效。
不过Flutter在OpenHarmony上的支持走的是社区路线，不是官方主干直接支持。OpenHarmony SIG组维护了一套flutter_flutter仓库，通过fork官方Flutter SDK并增加ohos平台适配，才能构建出OpenHarmony可识别的产物。这套方案的好处是API和标准Flutter基本对齐，坏处是SDK版本滞后于官方主干，且依赖DevEco Studio配合构建。
实测下来，Flutter for OpenHarmony在API 9到API 11的设备上都能跑，但性能表现有差异。中低端设备上，Flutter的Impeller渲染器在OpenHarmony上的支持还不够成熟，我最终在release模式下关闭了Impeller，切回Skia渲染，稳定性明显提升。这个细节后面在常见问题部分会展开。
1.3 等级系统的风控与防刷设计
等级系统最怕的就是刷经验。剧本杀场景里，如果有人反复建队再解散、或者找小号互刷评价，经验值体系就会失真。我在设计经验值获取规则时，引入了三个防刷约束：单日获取上限、行为冷却时间、低质量行为惩罚。
单日上限容易理解，比如每日通过组队获得的经验上限是200点。行为冷却时间针对的是频繁操作，用户解散队伍后24小时内再次建队不计经验。低质量行为惩罚则是针对恶意刷评价——如果同一批次队友连续三场给出雷同评价，系统自动标记并冻结该批次经验。
这些规则在服务端做硬校验，客户端只负责展示规则和当前进度。这样的拆分让等级系统即便被反编译也能保住底层逻辑，客户端拿到的永远是服务端算好的经验值和等级快照。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 等级与特权系统核心设计
2.1 等级成长曲线与经验值计算
等级成长曲线我采用的是分段式指数增长，而不是简单的线性累积。原因很简单：线性增长会让高等级失去稀缺性，纯指数增长又会让前期升级太慢、用户流失。分段式方案在前期升级快给反馈，中期稳步爬坡，后期靠门槛维持高端用户的荣誉感。
具体配置上，我设计了10个等级。Lv.1到Lv.3是新手期，100经验升一级；Lv.4到Lv.6是成长期，250经验升一级；Lv.7到Lv.9是成熟期，500经验升一级；Lv.