在构建视频预览或动态素材库时，我们经常需要实现一种效果：鼠标悬停在某个分类上，一次性看到该分类下 10 多个动图的“网格预览”。

如果直接加载 10 多个独立的动态 WebP，浏览器会面临巨大的解压压力和连接数限制。将这些动图合成为一张“动态大图” 是终极优化方案。但如果你简单地进行拼接，你会发现：有些格子在闪烁，有些格子播完一遍就变黑了。

本文将深度探讨如何通过“补帧”策略规避这一问题。

---

1. 核心痛点：为什么会闪烁？

动态 WebP 本质上是一系列帧的集合。当你尝试将 A 图（10帧）和 B 图（30帧）合成到同一个容器时，问题就来了：

• 帧数失配：合成后的 WebP 必须有一个统一的总帧数。如果设为 30 帧，那么 A 图在第 11 帧到 30 帧之间是“缺失”的。
• 渲染黑屏/闪烁：浏览器在渲染该帧时，如果某个坐标区域没有数据，可能会显示背景色或上一缓存帧，导致剧烈的视觉闪烁。
• 循环不同步：不同素材的 delay（帧间距）不同，会导致某些格子播得快，某些播得慢，整体观感极度混乱。

---

2. 解决方案：补帧对齐策略 (Frame Padding & Looping)

要实现完美的网格预览，核心逻辑不是简单的空间拼接，而是时间维度的重构。

2.1 确定全局基准

首先，遍历所有待合成的 WebP，获取它们的元数据（帧数、帧延迟）：

1. 统一帧延迟：强制所有素材使用相同的 delay（例如 100ms/10fps）。
2. 计算目标总帧数：通常取所有素材中最大的帧数，或者取它们的最小公倍数（为了完美循环）。

2.2 补帧逻辑（关键）

对于每一张图片，我们采用“取模循环”进行补帧：

• 假设目标总帧数为 60 帧。
• 图片 A 只有 20 帧。
• 在合成第 i 帧大图时，图片 A 应该取第 i % 20 帧的数据。
• 结果：图片 A 在大图中循环播放了 3 次，而图片 B（60帧）刚好循环 1 次。两者完美填满了整个动画周期，彻底消除闪烁。

---

3. 技术实现 (Node.js + Sharp + WebP-Muxer)

由于 Sharp 本身对“多帧动态合成”支持有限，我们通常采用 “拆解 -> 复合 -> 重组” 的流水线。

第一步：拆解与缩放

将每个输入 WebP 拆解为独立的帧序列，并统一缩放至目标尺寸。

第二步：网格复合 (Composition)

这是计算量最大的部分。我们需要运行一个循环，次数等于“目标总帧数”。

const sharp = require('sharp');

async function composeFrame(frameIndex, sourceImages, gridConfig) {
  const layers = sourceImages.map((img) => {
    // 补帧逻辑：取模循环
    const pageIndex = frameIndex % img.totalFrames;
    
    return {
      input: img.frames[pageIndex], // 该素材的对应帧
      left: img.x,
      top: img.y
    };
  });

  return await sharp({ /* 透明大背景 */ })
    .composite(layers)
    .toBuffer();
}

第三步：重组为动态 WebP

将生成的每一帧“大图”重新封装回一个动态 WebP 文件。

---

4. 极致优化建议

4.1 内存管理

合成动态大图极度消耗内存（因为每一帧都是大分辨率）。

• 不要使用 Promise.all：建议使用顺序执行或限制并发的队列。
• 流式处理：如果可能，将帧直接写入磁盘缓存，最后统一封装。

4.2 丢帧与抽帧

如果原始素材是 60fps，合成预览图时建议强制抽帧到 10fps 或 12fps。这能显著减小文件体积，且对于预览场景来说感官影响很小。

4.3 预读取元数据

使用 ffprobe 或 sharp.metadata() 提前获取所有素材的 pages（帧数），计算出最佳的合并方案，避免中途出错。

---

5. 总结

实现“动态 WebP 网格预览”的难点不在于空间上的 x, y 坐标，而是在于 “时间轴对齐”。

通过取模循环补帧，我们可以确保在动画的每一毫秒，网格中的每一个格子都有有效的数据。这不仅规避了闪烁，还让你的素材库预览看起来像是一个整齐划一的“电视墙”，极大提升了产品的工业感。

---

技术关键词：WebP Animation, Frame Synchronization, Node.js Sharp, CDC, 补帧策略