极短的加载时间内出现指示反而会制造多余的视觉闪烁
别名: 等待闪一下 · 过早进入等待态 · premature wait chrome
概念解释
骨架还是转圈，都是进入等待呈现之后的事。若这次加载在人还把动作算作「正在发生」的窗口内就结束，两种指示都不该出场。出场又立刻收掉，屏幕多一次无意义的状态闪：闪烁（flicker）。闪烁不是诚实，它把一次已经完成的操作改写成一次等待，再把等待取消。等待策略的第一刀不是选骨架还是转圈，而是这次够不够格被当成等待来呈现。
组件怎么延迟转圈、出场后最少显示多久，是指示器那一组的时序。这里管的是策略：短于门槛的请求，根本不要切进等待态。
机制
人对刚发出的动作有一段仍算「同一件事」的时间。这段里屏幕可以不变，绑定还不破。一旦骨架或转圈插入，同一段钟表时间被重新编码成「我在等系统」——编码切换本身是一次状态变化。请求若在这一帧或下一帧完成，人看到的是：按下 → 等待皮 → 完成，三拍里中间那拍没有信息量，只有一次抢注意的亮灭。注意会被闪烁吸走，还会留下「系统比实际更忙」的印象，于是开始重复点、或觉得产品不稳。
门槛不是审美。本地筛选、缓存命中、已经预取好的下一页，经常落在窗口内；跨网络的冷请求经常落在窗口外。策略若「有请求就切等待态」，等于把大量本不必呈现的等待强行呈现。骨架在这里并不比转圈更无辜：整页灰块闪一帧，比一只小转圈更吵，因为改写的像素面积更大。
怎么研究
在同一操作后注入可控延迟，比较「一发出请求就进入等待呈现」和「过了门槛再进入」。关键对照是客观时间其实很短、但等待皮闪过的条件。
自变量：延迟长度、等待皮的种类（骨架 / 转圈 / 无）、操作是否已有按下态之类的即时确认。 因变量：是否报告「刚才卡了一下」、重复点击、把已完成动作记得更慢、主观不稳定。
不要把「有没有看见指示」当成功指标。短延迟里看见正是失败：人被训练去监测一次本不存在的等待。实验室被试知道自己在等加载，比产品用户更容忍闪一下；产品里闪烁会和按下态、路由转场叠在一起，要把这些即时反馈从「等待呈现」里拆干净再比。
边界
按钮没有任何按下态时，人需要别的即时确认，那是操作点的反馈，不是批准进入等待态。用户已经把这次动作建构成慢过程（导出、支付、安装），门槛可以更低，因为预期已经是等待，缺指示会被读成没点上。弱网把「通常很快」变成「经常很慢」时，固定门槛会让等待呈现经常迟到，人在门槛内开始连点；这时要配防重入，而不是把门槛降到零、让快请求重新闪。骨架准入（结构可预知）不能覆盖这条：结构再清楚，几十毫秒的请求也不该整页刷灰。
怎么落地
- 给「进入等待呈现」设门槛。短于门槛结束的请求保持当前界面，只保留操作点上的即时态。
- 门槛按操作类型分开：本地过滤可以更久才承认在等，冷启动的跨网请求可以更短。
- 骨架和转圈走同一道门，不要「转圈延迟、骨架立即」。整页骨架闪一帧是更重的闪烁。
- 验证：在快网或缓存命中下连续做常见动作，逐帧看有没有单帧等待皮。有，就把进入等待态的延迟调到刚好盖住这些快请求。