1. 背景与痛点分析
当前 Tanka 平台在网络慢或异常时，页面加载和异常反馈存在明显的体验断层。主要表现在以下两个方面：
目前多处直接在页面中央弹出一个黑色的 Loading 方块。这种设计视觉过重，且存在“有的地方有、有的地方没有”的无序状态，导致页面内容加载时产生强烈的视觉跳动感。
网络异常或接口报错时，页面基本处于“无反馈”状态（白屏或卡死在加载态），缺少明确的错误提示和“重试”按钮，用户只能被迫手动刷新整个网页。
2. Loading 场景分类矩阵
加载状态不能一刀切。我们需要根据触发时机、内容形态、耗时预期、是否阻塞四个维度，将场景细分并匹配最合适的设计表现。
| 场景类型 | 触发时机 | 内容形态 | 耗时预期 | 是否阻塞交互 | 推荐加载方案 |
|---|---|---|---|---|---|
| 首屏冷启动 | App/网页首次打开 | 无（全白状态） | 1s - 3s | 完全阻塞 | 极简 Logo 呼吸灯 / 品牌 Spinner |
| 模块/路由切换 | 点击导航切换大模块 | 整页/大区域内容 | 500ms - 2s | 部分阻塞 | 顶部进度条 + 局部骨架屏 |
| 结构化数据加载 | 进入列表、卡片页 | 消息流、群组、Memo列表 | 500ms - 1.5s | 不阻塞 | 骨架屏 (Skeleton) |
| 用户主动提交 | 点击发送、保存、创建 | 按钮、输入框、小卡片 | < 1s | 局部阻塞 | 按钮内 Spinner / 局部小转圈 |
| 不确定耗时任务 | AI 生成、大文件解析导入 | 自由文本、复杂图表 | > 3s (长耗时) | 不阻塞 | 渐进式反馈 (打字机/步骤文案) |
3. 细分加载方案与视觉示意
骨架屏 (Skeleton)
在真实数据未返回前，绘制出与真实内容排版一致的灰色占位块。加载完成后原地替换，避免视觉跳动。
Spinner / 局部小转圈
用于按钮、输入框或局部小组件的异步操作。不阻塞页面其余部分的交互，视觉干扰极小。
顶部进度条 (Progress Bar)
在页面顶部边缘显示一条极细的进度线。适用于大模块切换，给用户一种“轻快、无缝”的浏览体验。
渐进式反馈 (Progressive)
针对无法预估耗时的复杂任务（如 AI 生成），通过打字机动效或阶段性文案，向用户传达“系统正在努力工作”。
首屏冷启动 (Splash)
应用刚打开、没有任何结构可预告时。使用极简的品牌 Logo 呼吸灯或居中 Spinner，建立第一视觉锚点。
全局居中黑色方块
黑色方块视觉过重，强行打断用户视线。且由于是绝对定位居中，在不同尺寸屏幕上极易遮挡关键操作，造成“假死”错觉。
4. 加载失败 (Error State) 规范
当加载失败时，必须提供明确的反馈和出口。禁止白屏或无响应。
1 区分错误类型与文案
- 网络异常（客户端问题）：提示“网络连接似乎中断了，请检查您的网络设置”。
- 服务异常（服务端问题）：提示“服务器开小差了，请稍后再试（错误码: 500）”。
2 强制提供“重试”机制
失败态卡片中必须包含一个高亮的“重新加载”或“重试”按钮。点击后，局部组件重新发起 API 请求，并回到 Loading 状态，无需用户手动刷新整页。
3 与“空状态”进行视觉区分
避免混淆。空状态（No Data）代表系统正常但无内容，插画应偏向中性、轻松；加载失败（Error）代表系统异常，插画或图标应使用警示色（如琥珀色/红色），并带有明确的断网或感叹号隐喻。
网络连接异常
无法连接到 Tanka 服务器，请检查您的网络连接是否正常。
5. 落地与收敛建议
由设计团队输出统一的 Skeleton、Spinner、ErrorState 组件规范，开发封装进公共组件库，严禁各页面自行写死 Loading 样式。
优先替换核心高频页面（如 Chat 消息流、Memo 列表、搜索结果页），废弃黑色方块，逐步向骨架屏和局部 Spinner 过渡。
在前端 API 请求拦截器（Axios/Fetch Interceptor）中统一处理 5xx/网络断开等异常，自动触发全局或区域的 ErrorState 组件，确保兜底。