完整序列转 APNG：保留每一帧延时与透明层次，同时盯住移动端解码内存峰值与首屏 LCP 是否被大块动图拖垮
`animated-gif-apng` 适合把长段 UI 演示、产品微动效或教程动图从 GIF 调色盘迁到真彩色序列；风险在于帧数一多，APNG 解码缓冲区与主线程绘制成本会明显高于同等像素的短 GIF。若页面同时挂载多条 APNG，低端机会出现掉帧或短暂卡顿。需要为「全量帧保留」与「体积/性能」设硬指标：例如限制最长边、合并静止背景为单帧、或对中间过渡帧降采样。验收时除肉眼循环外，应用性能面板看合成层与内存曲线，避免仅实验室 Wi‑Fi 通过。
长序列 GIF→APNG：先锁帧表与总时长，再优化区域更新与背景复用，最后在低端机做内存与掉帧采样
- 在批量导出前先整理帧表 CSV：索引、延时、是否全幅替换，确认与产品稿标注一致；标记可合并的重复帧与可裁切的更新矩形，减少无意义的整画布 `fdAT`。
- 在 iPhone 中端与一款三年前的 Android 上连续播放十分钟，观察是否因温控降频导致周期掉帧；同时记录文件大小与 TTFB，防止首包把 LCP 挤出预算。
- 若仍超预算，生成分档：`hero` 全质版与 `feed` 降采样版，并在 CMS 绑定场景字段；版本号写入文件名，避免运营误把 4K 级 APNG 插进列表卡片。
完整序列变体问答：帧数、内存、分档与多实例同页
GIF 只有几十帧，转 APNG 后文件反而大几倍，是不是「真彩色」必然吃亏，还有哪些编码层面的浪费可砍？
真彩色确实可能更大，但很多时候浪费来自重复全幅帧或未压缩大块透明区。应检查是否每帧都在全画布重绘、可否把静态背景抽成底层、能否合并相邻相同延时。用工具看每帧压缩后体积分布，优先砍掉体积最大的几帧往往比全局降码率更有效。
同一页面挂三个 APNG 小图标就卡，是解码并行太多还是单个文件内部 dispose 设置导致过度合成？
先单文件播放看 CPU：若单文件已高负载，多半是分辨率过大或 blend 链过长。多实例场景要限制同屏同时播放数量、用 `IntersectionObserver` 暂停视口外动画，并避免在滚动容器里叠多层半透明 APNG。必要时把其中一个换成 CSS 或 Lottie。
产品坚持「一像素都不能丢」，但性能红线过不去，如何用可视 diff 说服他接受合并过渡帧？
对合并候选帧做 SSIM 或快速 flicker 对比视频，标注人眼不易察觉的区间；给出合并前后体积与帧时间线对比表。把「可感知质量」写成阈值而不是口号，评审会上用数据投票而不是凭感觉否决优化。
导出后某一两帧与源 GIF 颜色略有偏差，是 gamma 还是浏览器色彩管理差异，如何定责？
在 sRGB 工作流里先排除源是否嵌了不同 ICC；再用同一屏幕并排截图比较。若仅 Safari 与 Chrome 不一致，查是否一方做了额外色彩匹配。不要在未校准显示器上口头定责，保留三方抓屏与嵌入的配置文件信息。
需要给无障碍用户「减少动效」提供静止替代，APNG 应配什么元数据或并行资源？
在 CSS 层尊重 `prefers-reduced-motion` 切换为单帧 PNG 或低帧率版本；HTML 可提供同尺寸 `poster` 并在媒体查询里替换 `src`。不要把责任全推给系统设置而不提供替代 URL，否则审核与投诉仍会落到产品。