关键帧封面转 JPG：写死帧号与 flatten 色，别让黑场首帧或透明边灰雾当上列表与分享卡的「主视觉」
`gif-frame-jpeg` 用于列表封面、推送大图与 Open Graph：必须把「哪一帧代表活动」写死，避免 API 默认 frame0 却是黑场。JPG 适合带宽敏感链路，但 progressive 与 baseline 对 LCP 与社交抓取表现不同。裁切安全区要预留圆角卡片与状态栏遮挡。
`gif-frame-jpeg`：从时间码到分享调试器与列表卡片宽度的双重验收
- 确认封面帧索引或时间码，附示意圈选；按渠道输出多套长边（例如 1200/800/640）并统一命名后缀。
- 在真实列表卡片宽度与 OG 调试工具里各验一版；检查字幕底部是否被 `object-fit: cover` 吃掉。
- 上线后抓分享调试器与新 CDN URL，确认未被转成 WebP 再截静帧；缓存用新文件名避免旧封面长缓存。
封面帧 JPG 问答：裁切、渐进、平台二次压与缓存指纹
分享卡片里封面发灰发脏，是 GIF 量化问题还是 JPG 质量开太低？
先在与线上一致的宽度下对比源 GIF 该帧与 JPG；若源已脏，提质量没用。若源干净 JPG 脏，提高质量或换用稍大画布再让平台缩。记录各平台二次压缩的可见阈值。
只换了封面 JPG 的 URL，App 里仍显示旧图，是客户端磁盘缓存还是 CDN 边缘没失效？
比对响应头 `ETag`/`Last-Modified` 与文件哈希；若路径未变，App 与 CDN 都可能长缓存。应用新文件名或强版本 query 并联动刷新；同时抓包确认不是仍指向旧对象键。
运营抱怨 progressive JPG「先糊后清」像故障，技术要保留渐进以优化 LCP，怎么统一口径？
在需求里写明「渐进加载为预期行为」并提供首屏占位底色；若品牌不接受，封面这条链路可单独改 baseline 并量化 LCP 得失再决策，而不是口头争吵。
同一母图要出 1200、800、640 三档，应对每档分别调质量还是统一高质量再缩放？
优先一份高质量母图经同一工具链缩放，避免三档各用手调导致色偏不一致；每档可微调质量以满足 KB 上限，但要在脚本里参数化而非手工。
活动下线只删了 JPG 封面，深层 GIF 仍被爬虫索引，会带来什么合规或品牌风险？
搜索与社交仍可能展示 GIF 动效或旧 OG；下线应同步处理 robots/分享刷新或替换占位图，并在工单记录「动静态一并退役」而不仅是删静帧。