状态与场景：让切换、暂停和恢复可预测

“显示暂停面板”与“游戏暂停”不是同一件事。前者是界面变化，后者需要明确哪些系统停止、哪些继续、哪些输入仍然允许。

场景组织内容，状态决定当前允许发生什么。 一个场景可以包含多个业务状态，一个业务流程也可以跨多个场景。

先写状态，再写按钮

状态机不是一定要安装的框架。小项目用一个枚举和明确的转换方法就可以起步。关键是把允许的转移、进入动作和退出动作集中表达，避免每个按钮随意操作多个系统。

暂停影响什么

系统	常见选择	需要说明
玩法输入	停止	正在拖拽的操作如何取消
物理与玩法计时	停止或冻结	使用何种时间基准
UI 按钮与过渡	继续	是否使用不受 timeScale 影响的时间
网络请求	视需求继续或取消	返回时结果如何应用
音频	按策略暂停或降低	与平台中断的关系

Time.timeScale = 0 不是完整暂停方案。它会影响使用缩放时间的逻辑，但不会自动停止所有输入、异步任务和平台回调。

场景切换的生命周期

场景加载时，旧场景对象可能被销毁，新对象开始初始化。长寿命服务若确实需要跨场景保留，可以使用合适的启动对象和持久化方式，但要避免每个场景都生成第二份。

加载场景之前，明确谁持有存档、平台服务和当前账号；加载之后，明确谁把状态绑定给新视图。全局单例可以简化访问，也可能隐藏依赖，优先让启动流程可解释。

取消与晚到的结果

假设玩家点击“加载关卡”，随后立即返回菜单。资源加载完成时，如果仍然自动打开关卡，就出现了过期请求污染当前状态。

可以为加载会话分配标识，只有与当前会话一致的结果才应用；可取消的请求及时取消。对象被销毁后回调还尝试刷新 UI，也属于相同的生命周期问题。

交给 AI 的切换说明

请列出菜单、游戏、暂停和结算的允许转移。每个转移说明输入锁、计时、音频、拖拽取消、存档和异步回调如何处理。先用最简单的状态表示实现，不引入状态机插件。

验收连续点击开始、暂停时开广告、加载时返回、结算后重开和后台恢复。每一步都应能回答“当前状态是什么、哪些操作被允许”。参考：场景管理、Time.timeScale。