从原型到游戏状态机

后端经验在这一章最有用：把界面外观与业务状态分开，再为事件定义可接受的转移。

卡牌状态与游戏阶段

卡牌记录身份和显示状态；整局游戏记录当前阶段。只给每张牌一个 isOpen，不足以表达比较期间禁止输入、暂停和结算。

游戏阶段：idle → selecting → comparing → selecting / completed
                               └→ failed
暂停：保存进入前阶段，恢复后继续；不要重新洗牌
卡牌状态：hidden / revealed / matched
mismatch：可作为反馈阶段的视觉投影，不必强行永久存储

以上是设计模型，不强制某种代码实现。关键是能解释每次事件是否允许、会改变哪些数据和何时结束。

最小事件契约

事件	前置条件	结果
pick(cardId)	selecting，卡未配对，且不是已选第一张	翻开并记录选择
第二次 pick	第一张已选择，第二张是另一张牌	进入 comparing，锁输入
compare 完成	两个有效 cardId	相同则 matched；不同则反馈后隐藏
pause	当前允许暂停	保留布局、选择和计时策略
restart	允许重开且玩家确认必要损失	清理旧回调、计时、选择并建立新局

快速连点同一张牌不能伪造配对；第三次点击不能闯入比较阶段。旧动画或旧网络请求完成后，也不能修改新一局数据。

设计如何表达异常

图层不能替你执行幂等，但需要表现异步过程。比如奖励领取至少区分可领取、提交中、已领取和失败可重试；只有按钮变灰，没有原因和恢复路径，仍然是不完整的设计。

本次案例范围中，奖励展示是静态教学数据，不连接真实发奖接口。开发交付会明确该边界。

请为翻牌写事件表，不先画图。
覆盖同卡重复点击、第三张抢点、比较中暂停、后台恢复、重新开始。
每个事件写允许阶段、状态变化、视觉反馈和恢复策略。
最后指出原型已演示的路径，以及必须由微信运行时实现的逻辑。

练习与检查

推演：第一张翻开后，玩家迅速点第二、第三张，再切后台。写出恢复时应该显示什么，以及过期回调如何被识别。若设计和代码对这些问题给出不同答案，应先统一规格。

依据：Figma 原型状态管理、微信运行环境。核查：2026-10-31。