加载与弱网：让等待有解释
同样等待几秒，“正在准备棋盘资源”和完全没有变化，会让玩家采取不同动作。前者解释发生了什么，后者可能引发连点、退出和重新打开。
先区分正在等什么
方块小岛可能等待代码、图片、棋盘生成、关卡数据或进度确认。它们的风险不同：资源未准备好时不能开始操作，确认进度时则要避免把未落地的结果显示为已保存。
不要所有阶段都写“加载中”。可以说明当前阶段，但不必把文件名、HTTP 错误和内部模块名暴露给玩家。
先体验正常、慢网和断网
交互实验正在准备…请启用 JavaScript。
真实进度与阶段反馈怎样选择
如果你知道需要处理的任务数，可以按真实完成情况表达；但不同任务耗时差别很大时，“完成 9/10”不代表只剩十分之一时间。进度定义应与玩家理解接近。
如果无法可靠计算，就显示阶段或不确定进度，并提供必要控制。不要用一个匀速增长到 99% 的数字假装知道剩余时间。
重试要保持上下文
玩家已经选了第 3 关，失败后不应该无缘无故回首页重新选择。重试应保留有效输入、关卡和已确认进度。
同时规定技术边界：是否取消前一个请求？旧请求晚到是否忽略？重复点击会不会发起多次初始化？如果重试需要重新扣资源，必须先重新审查规则和玩家承诺。
超时也要有明确语义：只是界面不再等，还是远端操作已经取消？涉及资源或结算时，不能因为本地超时就断言远端失败，再无条件重复操作。
给 AI 的要求
为关卡加载设计 idle、loading、ready、error、cancelled 状态。
网络失败保留关卡与输入；重试时不重复创建当前局。
能计算时显示实际进度，不能计算时说明阶段。
分别说明取消、超时和旧结果晚到的行为。
不要把请求已发送当成进度已保存。
动手练习
将测试网络设为慢网和断网，观察四个时刻：点击后、等待中、失败时、重试后。记录玩家在哪个时刻不知道该怎么办，再针对这个空白设计反馈。
系统状态需要可见，是 Nielsen 易用性启发原则中的一个方向。本章加载模型、计时参数和具体文案为原创教学方案，不是通用性能阈值。