[杂谈] 活动脚本最怕的不是报错，而是边界状态没处理

tibaiwan1888

做活动脚本时，很多人只测“正常流程”：玩家进入活动、打怪、领奖、退出。这个流程当然要测，但真正容易出事的往往是边界状态。

我整理了一些活动脚本常见问题：

1. 活动结束瞬间玩家还在副本里
如果没有统一清场逻辑，玩家可能继续刷怪、继续领奖，甚至把活动地图当成永久地图用。

2. 玩家掉线后重连
掉线前已经进入活动，重连后要不要回原地图？活动结束了怎么办？如果没有记录进入前地图和坐标，传回去就很麻烦。

3. 重复点击 NPC
玩家连续点两次“进入活动”，如果脚本没有加状态锁，可能重复扣材料、重复传送、重复创建副本。

4. 奖励发放和排名结算不同步
排行活动最容易出问题。比如活动结束后排行榜还没排序完，玩家已经领奖；或者玩家分数更新晚了一秒，导致排名错位。

5. 服务端重启
临时变量如果只存在内存里，重启后活动状态就丢了。重要活动最好保存活动期号、玩家分数、领取状态。

活动脚本建议统一使用“活动期号”设计。

例如：

活动期号 = 20260606_2000

玩家积分 key：
event:score:20260606_2000:角色名

领奖状态 key：
event:reward:20260606_2000:角色名

这样做有几个好处：

- 每一期活动互不影响
- 可以查历史数据
- 玩家不能拿上一期状态混到下一期
- 出问题时可以只补偿某一期

另外，活动最好设计成状态机：

未开启 -> 报名中 -> 进行中 -> 结算中 -> 已结束

每个状态只允许做对应的事：

- 报名中：允许进入，不允许打分
- 进行中：允许打怪、计分
- 结算中：禁止进入，准备排行
- 已结束：允许领奖或清理

状态机看起来麻烦，但能避免大量 if 判断互相打架。尤其是多人活动、跨地图活动、排行活动，非常值得用。

一句话：活动脚本不要只测试“玩家很听话”的情况，要假设玩家会狂点、掉线、卡点、跨天、重进、组队、背包满、网络抖动。

tibaiwan1888

一句话：活动脚本不要只测试“玩家很听话”的情况，要假设玩家会狂点、掉线、卡点、跨天、重进、组队、背包满、网络抖动。