游戏客户端 Toast 与通知队列：提示越短，规则越要清楚

短提示也会打架

Toast 看起来很小：获得金币、网络错误、背包已满、任务完成、好友上线、活动开启。每条只显示一两秒，但游戏里同时触发的提示非常多。如果没有规则，屏幕上会连续冒出一串提示，互相覆盖，甚至挡住战斗操作。

提示系统要回答几个问题：谁能显示，显示多久，能否合并，优先级如何，当前场景是否允许，玩家是否已经看到，重复提示要不要节流。越短的提示，越容易被忽略，也越需要清楚规则。

提示要分类

获得类、错误类、状态类、社交类、系统类、教学类提示不应该走同一套逻辑。获得类可以合并，错误类要尽快显示，系统类可能需要更高优先级，教学类要避免和引导冲突。

flowchart TD
    A[业务提交提示] --> B[提示分类]
    B --> C[上下文检查]
    C --> D{允许显示?}
    D -->|否| E[延迟/丢弃/转日志]
    D -->|是| F[合并与节流]
    F --> G[优先级队列]
    G --> H[展示通道]
    H --> I[完成回调和统计]

上下文检查很重要。战斗中不要弹低优先级社交通知，剧情对白中不要弹活动广告，新手引导强制点击时不要让 Toast 遮住目标。

合并减少噪音

玩家连续获得 10 个材料，不需要显示 10 条 Toast。可以合并成“获得材料 x10”，或者按类型汇总。合并窗口不要太长，通常 0.5 到 1 秒足够。太长会让反馈变慢。

错误提示也需要节流。网络抖动时，同一个接口失败可能连续触发多条“网络错误”。客户端应在短时间内合并重复错误，只显示一次，并在详情日志里记录全部失败。

优先级不能只靠业务自报

每个业务都觉得自己的提示重要。如果完全让业务传 priority，队列会失控。提示系统应该定义固定等级：阻断系统提示、关键错误、当前操作反馈、奖励获得、社交通知、低优先级推荐。业务只能在自己的范围内选择。

高优先级提示可以打断低优先级，但也不能无限打断。系统强更、断线、封禁这类提示不应走普通 Toast，而应走系统弹窗或覆盖层。Toast 适合短反馈，不适合承载需要决策的信息。

展示通道要分离

屏幕中上方、底部、聊天区域、奖励飞字、战斗提示，是不同通道。一个全局 ToastManager 可以统一调度，但渲染通道要分开。战斗提示不应和背包获得提示抢同一个位置；聊天通知不应挡住技能按钮。

每个通道要有容量。比如底部 Toast 同时最多 2 条，中间关键提示最多 1 条，奖励滚动条可以排队。容量满时，低优先级提示延迟或丢弃。

文案要有行动指向

“操作失败”是很差的提示。玩家需要知道为什么失败，以及能做什么。背包满了就提示整理背包，网络断了就提示重试或等待，活动未开启就显示开启时间。短提示也要具体。

不过 Toast 不适合长解释。复杂错误可以显示短文案，并提供详情入口或在对应界面展示完整说明。短提示负责即时反馈，不负责完整教学。

动画和可访问性

Toast 动画要短、稳定、不会遮挡。过度弹跳和强闪烁会干扰操作。对色弱和低视力玩家，不能只靠颜色表达错误或成功。重要提示可以配合图标和音效。

如果游戏支持朗读或辅助功能，Toast 也要进入可访问提示队列。但不要朗读所有低优先级获得信息，否则会造成噪音。

统计能发现问题

提示系统可以统计每个场景每分钟显示多少条、哪些提示被合并、哪些被丢弃、玩家是否立即执行相关操作。如果某场景 Toast 过多，说明业务反馈过密；如果某错误提示频繁出现，说明背后可能有系统问题。

QA 也可以用提示日志排查。玩家说“刚才弹了一条看不清的提示”，开发版能看到最近提示队列和来源模块，定位会快很多。

小结

Toast 是客户端反馈系统的一部分，不是随手弹一行字。分类、上下文、合并、优先级、通道和统计，让短提示既及时又不打扰。提示越短，规则越要清楚。

提示来源要可追踪

每条 Toast 都应该知道来源模块和业务 ID。玩家反馈“刚才弹了个提示看不清”，开发版能查最近提示队列，看到是哪个系统提交的、为何被合并、是否被丢弃。没有来源，提示系统很难治理。

来源信息也能用于限流。某个模块短时间提交过多低优先级提示，可以整体降级或合并。提示队列不是无条件收消息的管道，它要保护玩家注意力。

错误提示和操作反馈分开

玩家点击按钮后，需要即时反馈“已提交”或“处理中”；请求失败后，需要错误原因。这两类提示不要混在一起。操作反馈通常绑定按钮或局部界面，错误提示可以用 Toast 或弹窗。

如果所有反馈都走全局 Toast，玩家可能不知道是哪次操作失败。局部错误优先显示在局部，只有跨系统或非当前界面的错误才进入全局提示。

奖励提示要和背包状态一致

获得道具的 Toast 很常见，但它不能和真实背包状态冲突。客户端可以先显示服务端确认的奖励，再更新背包。不要在请求提交时就弹“获得”，否则失败或回滚时会造成投诉。

批量奖励可以分级展示：重要稀有物品单独提示，普通材料合并，货币进入汇总条。这样既保留惊喜，也不刷屏。

场景切换时的队列处理

场景切换、进入战斗、播放剧情时，队列里的提示要处理。低优先级提示可以丢弃或延后，关键错误要保留，奖励提示可以在安全场景展示。不要让大厅里的活动 Toast 延迟到战斗中突然出现。

提示队列应支持上下文标签。提交提示时声明适用场景，场景变化后系统决定是否仍然有效。

测试提示风暴

提示系统需要压测：连续获得 100 个道具、网络错误连续触发、多个活动同时开启、聊天和系统通知同时到达、切场景时队列未空。观察是否遮挡操作、是否卡顿、是否有提示丢失关键错误。

越是小 UI，越容易没人系统测试。Toast 失控会让整个游戏显得吵。

提示和弹窗的边界

Toast 适合不需要决策的信息，弹窗适合需要玩家选择的信息。很多体验问题来自把两者混用：重要错误只弹一条很快消失的 Toast，玩家来不及看；普通奖励却弹模态窗口，打断操作。

客户端可以在提示系统里限制类型。需要确认、取消、查看详情的内容不走 Toast；只需告知的内容不走弹窗。边界清楚后，业务也更容易选择。

本地化长度

Toast 文案短，但本地化后可能变长。德文、俄文、英文和中文长度差异很大。提示容器要支持换行或截断策略，不要让文字溢出屏幕。重要错误不能被截断到失去意义。

如果空间有限，可以使用短标题加详情入口。不要为了适配长度，把所有语言都写得含糊。

声音和震动

部分提示需要音效或震动辅助，比如匹配成功、背包满、关键错误。但如果所有 Toast 都播放音效，玩家会觉得吵。提示系统可以按优先级决定是否触发声音和震动，并尊重玩家设置。

音效也要节流。连续获得奖励时，只播放一次汇总音效，比每条都响更舒服。

小结之外

提示系统管理的是玩家注意力。它要让玩家知道重要变化，也要保护玩家不被无关信息打扰。队列、优先级和上下文规则，最终都是为了这件事。

提示的生命周期

Toast 不是显示完就结束。它可能对应一个业务事件，展示后需要回调，比如奖励提示播放完再显示下一个稀有物品，错误提示展示后允许按钮恢复。提示系统应支持完成回调，但业务不能依赖回调做核心结算。核心状态必须先完成，Toast 只是表现。

如果玩家切场景或关闭界面，未展示的提示要按规则处理。奖励类可以汇总到下一安全场景，低优先级推荐可以丢弃，关键错误要保留到玩家能看到为止。

提示系统的调试面板

开发版可以显示当前队列、每条提示来源、优先级、剩余时间、合并状态和丢弃原因。业务抱怨“我的提示没显示”时，能直接看到是被上下文拦截、被合并，还是被更高优先级打断。

有了这个面板，提示系统就不再是黑盒，团队也更愿意遵守队列规则。

最后看三条底线

提示系统要守住三条底线。第一，关键错误不能被低优先级提示挤掉。第二，重复和批量提示能合并，不制造提示风暴。第三，提示有上下文，剧情、战斗、引导和场景切换时不会乱弹。

Toast 很短，但它直接管理玩家注意力。提示系统有规则，游戏会显得安静而可靠；提示系统失控，所有业务都会变成噪音。

维护成本来自入口太低

如果任何代码都能直接弹 Toast，提示系统很快会失控。业务应通过统一接口提交提示，并声明类型、来源、上下文和合并 key。队列根据规则决定是否显示。

这会让接入稍微麻烦，但能保护整体体验。提示系统是公共资源，不是每个业务的私有喇叭。

提示系统还要能承受运营高峰。节日登录时，签到、补偿、活动开启、好友上线、邮件到达可能同时触发。如果所有提示按提交顺序展示，玩家会被淹没。队列要在进入大厅的最初几秒做合并和排序，先显示当前最重要的结果，其余延后或汇总。

这类高峰最好在活动前压测，而不是上线当天靠玩家发现。

最后，提示系统要能被产品验收。开发版可以回放一组提示风暴，让产品看到合并、延迟和丢弃结果。规则可视化以后，业务更容易接受“这条提示不该现在弹”的结论。

提示系统还要和日志系统协作。不是所有被丢弃的提示都需要玩家看到，但关键丢弃原因应进入调试日志。比如战斗中丢弃了低优先级活动提示，这是正常；如果关键错误因为队列满被丢弃，就是规则 bug。没有日志，提示问题很难复盘。

长期看，提示队列也能反映产品噪音。如果某个版本每分钟提示数量翻倍，说明体验正在变吵。
最终验收时，要制造提示高峰并观察玩家是否还能操作。提示系统不是为了显示更多，而是为了让重要反馈被看见。