GIF 转 APNG：用 PNG 帧叠替代 256 色抖动，透明与渐变更干净，但要接受更大体积并显式配置 `image/apng` 与不支持端的回退
APNG 在每一帧上都能携带真彩色与完整 alpha，适合 GIF 调色盘压不住的半透明描边、柔和阴影与 UI 渐变；代价是文件往往更重、解码峰值更高，且部分旧版容器仍按「动图＝GIF」做转码或缓存。与 GIF 不同，APNG 用 `fcTL`/`fdAT` 描述逐帧延时与区域更新，错误映射 dispose/blend 会出现拖影或闪帧。上线前要写清：循环次数（有限次还是无限）、是否保留首帧静态兼容、CDN 的 `Content-Type` 与压缩策略、以及弱网下首包体积预算；否则会出现「本地预览完美、线上只播首帧或循环缺一圈」的假阳性通过。
GIF 转 APNG 落地步骤：先对齐时间轴与循环元数据，再验 dispose/blend，最后在目标浏览器与 CDN 响应头里各验一轮
- 导出前列出总帧数、每帧毫秒延时与 Netscape 循环次数，确认要映射成 APNG 的 `num_plays` 还是无限循环；约定最大边长与总字节上限，避免大图在低端机上解码掉帧。
- 在 Safari、Chrome 与目标 WebView 实机播放整段循环，重点看首尾衔接与透明边缘；用开发者工具核对响应为 `image/apng` 且未被中间层改成 `image/png` 静态首帧。
- 发布时版本化文件名或 query，归档源 GIF、APNG、编码参数与哈希；对不支持链路透传 `poster` 静图或回退 GIF，并记录哪一端走了降级以免误判转化率。
GIF 转 APNG 常见问题（MIME、循环、dispose、体积与兼容性）
产品问「APNG 一定比 GIF 省流量吗」，若导出体积暴涨两三倍，应从哪些旋钮收回预算而不把字幕糊成马赛克？
APNG 并不保证更小；先量化业务可接受的最大体积与首包时间，再尝试缩小画布、减少全幅帧、提高帧间差异压缩比例或合并相近延时。若仍超预算，应对外链与详情页分层：列表用短循环低分辨率，详情再换高质版，而不是强行全局压成一块糊动图。
线上只显示第一帧或循环少跳一次，是 `num_plays` 写错、CDN 剥了动画面板，还是 CSS/省流把动画关掉了？
先抓响应体是否含多帧 `fcTL`/`fdAT` 与正确 `Content-Type`；若字节完整仍不动，查 `prefers-reduced-motion` 与业务层是否把 `<img>` 换成静态占位。循环差一圈多半是 GIF 与 APNG 对「无限循环」与最后一帧 dispose 解释不一致，应用同一播放器对照源 GIF 数圈验证。
从 GIF 转来后某一帧出现鬼影或上一帧残影，应优先怀疑 APNG 的 blend 模式还是源 GIF 的 disposal 没翻译对？
对照源 GIF 在参考解码器里逐帧步进，记录每帧 disposal；映射到 APNG 的 `dispose_op`/`blend_op` 时，错误组合会产生累积残影。先锁定问题帧索引，再改 dispose 映射或改为全幅替换帧验证；不要一上来全局锐化，容易掩盖合成错误。
嵌入 App 内 WebView 或旧 Android 浏览器，APNG 完全不播，业务又禁止上视频，应选 GIF 回退、WebP 动图还是静态海报加手动播放？
按设备清单分层：对确认不支持的 WebView 提供同尺寸 GIF 或静态 `poster` 并在配置里显式切换；若允许 WebP 动画且覆盖更好，可二轨并行。关键是特征检测或版本白名单，而不是让用户面对空白动效；同时监控回退命中率避免报表把「没播」当成「没人点」。
法务已审过原始 GIF，换成 APNG 后是否还要重新审一遍，哪些像素变化会触发「新素材」认定？
格式变更若未改内容语义，多数流程可走「同案号增补格式」；但若重编码改变了字幕可读性、边缘透明度或出现裁切，审核方可能视为新稿。应在工单附双格式哈希对比与 diff 截图，涉肖像与商标的帧逐帧核对，避免仅换容器却触发合规真空。