A5.04.2Discrete UI refresh as a change-blindness trigger设计
无过渡的界面刷新会导致变化被漏掉
别名: 硬切 · hard cut · state-driven re-render
概念解释
界面默认的渲染方式是离散状态跳变——旧状态直接被新状态替换，中间没有任何过渡帧。这种"硬切"本身就等价于变化盲视经典范式里插入的那一帧空白：不需要用户眨眼或扫视，改动前后没有连续画面，检测所依赖的自动定向信号从一开始就不存在。
这让无过渡的界面刷新成为真实产品里出现频率最高的变化盲视触发源，比眨眼、扫视这类生理性中断更普遍——它发生在每一次"重新渲染"里，与用户当下的眼睛在做什么完全无关。
机制
声明式 UI 框架和大多数状态驱动的渲染管线，默认工作方式是：拿到新状态，重新计算视觉输出，替换旧的呈现。这个过程本身不带插值——除非开发者显式调用动画或过渡 API，否则从旧值到新值之间不存在任何一帧。实时数据更新（长连接推送、轮询刷新）也是同样的模式：数值直接从 100 跳到 105，没有滚动过渡。
因为这是渲染管线的默认行为，不是偶发的例外情况，它在真实产品里发生的频率远高于任何单一的生理性中断——每一次状态更新都是一次潜在的变化盲视触发，无论用户此刻的注意力在不在这块区域上。
边界
- 只覆盖状态更新本身没有插值的情形；如果框架或组件自带过渡（多数现代 UI 库的列表动画、路由切换动效），运动信号仍然存在，这种情况不算无过渡刷新。
- 更新发生在用户视野之外（滚动到不可见区域、切到后台标签页）时，问题的性质变成"根本没在看"，属于非注意盲视，不是这里说的变化盲视。
- 高频率的小幅数值更新（每秒跳动的计数器）即便没有过渡，用户也可能通过重复暴露逐渐感知到趋势变化。这里描述的是单次、离散、低频的状态跳变，不覆盖持续滚动的数字。
怎么落地
- 审查产品里所有"数据变了，界面立刻变"的路径：列表重新排序、筛选条件应用后的结果替换、后台推送覆盖当前显示值、跨设备同步覆盖本地状态、分页结果切换——这些都是无过渡刷新的高发点，逐条列出来审查，不要只假设"页面刷新"这一种情形。
- 优先审查用户没有主动触发的更新（后台推送、跨设备同步）：用户主动点击触发的刷新至少有操作意图作为提示，被动收到的更新完全没有预警，风险更高。
- 把"这次更新有没有过渡"列为组件上线前的检查项，写进代码评审或设计交付清单，而不是留给动效环节事后补救。
- 验证办法：把产品里所有状态更新的触发路径列一遍，标出哪些走的是硬切、哪些带过渡；硬切列表就是变化盲视的候选清单，逐条评估这个变化对用户是否重要到需要被确保看见。