瀑布流组件的异常处理，我设计了四种模式

原创: 云阁

发布于: 2026-03-25 20:00

6 天前更新

提示本文发布于 4 个月前，其中信息可能已经时过境迁...

做瀑布流组件的时候，最让我花心思的不是"怎么排版"，而是"出问题了怎么办"。

图片加载可能失败、网络可能超时、占位图也可能加载失败……这些异常情况在 Demo 里不会出现，但在真实业务里几乎一定会遇到。

四种异常类型

我梳理了一下，瀑布流里可能出现的异常其实就四种：

1. 图片加载失败 — 最常见的，网络问题或资源问题
2. 占位图加载失败 — 连兜底的占位图都加载不出来
3. 重试后仍然失败 — 重试了几次还是不行
4. 超时 — 超过最大等待时间还没加载完成

四种处理模式

针对这些异常，我设计了四种处理策略，调用方可以根据业务场景选择：

errorHandlingMode?: 'none' | 'placeholder' | 'retry' | 'fallback'

• none：直接结束，用默认高度占位。适合对图片要求不高的场景。
• placeholder：显示占位图。适合希望保持视觉一致性的场景。
• retry：自动重试 N 次。适合网络不稳定的环境。
• fallback：先重试，重试失败再显示占位图。最稳妥的方案。

状态机设计

每种异常类型对应一个状态，处理模式决定状态的转换路径：

原始内容加载
     ↓
   成功？
   ↙   ↘
  是     否
  ↓      ↓
 完成   根据模式处理
         ↓
    ┌─────────────────┐
    │  none: 直接结束  │
    │  placeholder:   │
    │    显示占位图    │
    │  retry: 重试    │
    │  fallback:     │
    │    重试→占位图   │
    └─────────────────┘

设计思想

核心就三点：

1. 异常类型是客观事实 — 不管什么模式，异常就是异常
2. 处理模式是主观策略 — 根据业务需求选择不同的应对方式
3. 渐进式降级 — 从最理想的状态逐步降级到可接受的兜底方案

所有模式都有超时保护，防止无限等待。这个设计后来也被我用到了其他组件里，算是一个可以复用的思路。