尚未加载。选好策略和结果，点上方「加载项目」。
换四种策略加载同一个列表
一个真实的项目列表区：选加载策略和请求结果，点「加载项目」，在列表物件上观察骨架、百分比、Spinner 或白屏的差别；到点看到真实内容，或切错误态看重试。
项目列表 · 加载策略实验台
同一个项目列表，换四种加载策略点加载：在列表物件上观察骨架占位、百分比推进、Spinner 转圈或白屏的差别，到点看到真实内容；切模拟失败再看原因和重试。计时器到点必须结束，绝不无限转圈。
加载策略
请求结果
对照四种加载策略：骨架屏保留布局、进度条给确定百分比、Spinner 只说在转、白屏没有反馈。选一种再点加载，在列表物件上看出差别；下一步切模拟失败看重试。
从刚才的操作里提炼
你在实验台上看到的就是加载状态的核心边界。
- 加载是异步反馈，要报告开始与进行：列表区设
aria-busy、用role="status"播报，让用户和读屏都知道请求已发出、还在进行。 - 骨架屏保留布局，感知最快：占位先撑起卡片几何，避免加载完瞬间整页跳动；到点替换成真实内容，用户感觉「快」。
- 长任务用进度条给确定性：百分比让用户预估还要多久；Spinner 和骨架没有这个信息，只能说明「在转」。
- 未知长度才用 Spinner / 骨架：估算不出比例时不要造假百分比；但必须有结束条件，不能无限转。
- 白屏和无尽转圈最差：没有反馈时用户分不清没点上、还在加载还是坏了——实验台里白屏那格就是反例基准。
- 必须结束，失败给原因和重试：成功显示真实内容，失败写明原因并提供重试；超时切错误态，绝不无限旋转，也不把错误伪装成空态。
什么时候关注加载状态
从用户信号判断，也要知道它的边界。
- 用：任何异步请求首屏——列表、详情、搜索结果；上传、导出、处理等长任务用进度条。
- 用：把加载、空态、错误态分开呈现和验收，不要互相伪装。
- 不用：同步即时反馈（按钮 active、本地状态切换）——那不需要加载态。
- 不用：纯装饰动效——加载反馈要承载「开始了、在进行、有结束」的信息，不是好看。
怎么用：从选策略到失败恢复的最短路径
让等待可感知、可结束、可恢复，并把结果落在物件上。
- 按等待特征选策略：已知长任务用进度条；未知长度但内容有固定布局用骨架屏；只剩「在转」信号用 Spinner；不要白屏。
- 加载开始立即在受影响区域设
aria-busy与role="status"，保留标题、筛选和上下文，按钮disabled防重复请求。 - 到点切换：成功显示真实内容；失败显示原因、
request id和重试——不要把错误伪装成空态，也不要无限转。 - 超时进入错误态而非无限旋转；重试不要重复危险副作用（如重复下单），可以用幂等键或先确认。
正反例：同一个列表加载，只改反馈设计
围绕同一个项目列表请求，只改变「加载时给什么反馈」，看用户后果如何不同。
列表先用骨架撑起卡片轮廓，aria-busy 报告进行中；数据到达交叉淡入真实内容；失败切错误态、写明原因并提供重试。用户始终知道在加载、何时结束。
整页空白或一直转圈，没有结束条件；接口失败时控制台静默报错，或把「加载失败」显示成「暂无项目」。用户分不清没点上、还在加载还是坏了，也无法恢复。
快速自测
项目列表接口偶尔要 8 秒才返回，部分用户网络更慢。下面哪种加载设计最扛得住？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。