转圈缺乏进度信息，长时间使用会被误认为卡死
别名: 转圈当卡死 · 无进度不确定指示 · endless spinner
概念解释
转圈是周期运动。周期运动证明「某个循环还在画」，不证明工作在前进。短等待里这够用：人只要知道系统没死。等待一旦拖过注意力还撑得住的窗口，同一只转圈会被重新分类——从「还在做」变成卡死（frozen）。人开始杀进程、重复提交、或把界面判为无响应。这条是不确定指示作为等待语言的时效上限：它没有进度信道，不能独自撑过长等待。
机制
「还在工作」和「工作走了多远」是两个问题。转圈的视觉只有相位，没有累计：第一秒和第三十秒可以长得一样，区别只在人记不记得自己看了多久。没有累计，人无法做资源分配——该继续盯、该切走、该取消，都只能靠猜测。猜测在短间隔里成本低；间隔拉长，猜测被「也许已经停了」占领，因为死掉的界面和一只永不改变信息量的转圈，从外面很难分。
周期运动还会自我麻痹。习惯化之后，转圈从信号变成背景纹理，活着的证据反而变弱。骨架在长等待里会变成「残缺的真页面」，那是另一种误读；转圈的误读是「循环还在、事情没有」。两种失败不同：一个是身份模糊，一个是进度信道缺失。选型时把转圈留给结构未知且预计不长的等待；一旦预计会越过窗口，必须换有累计的语言——阶段名、确定条、可查询的后台任务——而不是把转圈画得更大。
边界
游戏里的转圈、品牌启动画面，用户已经接受「这段就是过场」，误判卡死的阈值会更高，但不能无限高。确定进度若长时间停在同一个百分比，同样会被当成卡死，缺的不是转圈，是停滞时的阶段说明。本地计算打满主线程时，转圈本身也会冻住，这时「动着」这一条证据都没了，卡死判断几乎必然，需要把指示放到不依赖主线程的层，或改用系统级不阻塞的等待。无障碍若只播一次「加载中」再无下文，和视觉上的长转圈是同一类信道枯竭。不可取消的短握手（支付确认的几秒）可以暂时靠转圈，但必须真的短，并在开始前说明。
怎么落地
- 给转圈标时效：预计会越过注意力窗口的动作，不要只放转圈。升级到阶段文案、确定进度，或允许切到可查询的任务列表。
- 结构未知但任务会很长时，仍用不确定指示，但要配「正在做哪一类工作」的文字，让信息量随时间至少发生一次变化。
- 转圈必须动。主线程可能冻住的路径，把指示放在能独立刷新的层，避免「转圈也停了」。
- 验证：把一次请求拖到二十秒以上，只留转圈。问正在等的人「现在是在做还是坏了」。说不清，或已经去杀应用，就是转圈被当成卡死了。