老 CMS 转 JPG：上传白名单、KB 上限与后台二次缩放是最常见的「糊图三连」
`legacy-cms-gif-jpg` 面向十年前的 CMS：上传接口只认 `.jpg`、单文件几百 KB 封顶、后台用旧版 GD/ImageMagick 重新采样一次。GIF 直接传可能被拒绝或动效被剥只剩首帧，运营常被迫先转 JPG。风险在「二次缩放」：先在本机压很小再被 CMS 拉成模板宽，字幕会糊成一片。文件名若含中文或空格，老系统偶发 500。EXIF 里若带拍摄信息还可能违反内网脱敏要求。
`legacy-cms-gif-jpg`：先读模板真实输出宽，再让入库只做一次有损缩放
- 读出 CMS 模板实际输出宽度和上传上限 KB，按「只让后台缩一次」的原则定长边；文件名改 ASCII 加版本号，必要时先 strip EXIF。
- 在 staging 走完整发布流水线抓最终 HTML 里的图片 URL，核对是否被水印插件或 CDN 再压；对比本地 JPG 与线上字节大小。
- 为每条栏目写默认 flatten 底色与质量档位进配置表，禁止编辑在后台手滑质量条；升级 CMS 小版本后回归三张样板图。
老 CMS 问答：插件水印、衍生多尺寸与文件名编码
本机预览清晰，一进 CMS 就糊，是后台自动插了水印还是又被缩了一次长边？
对比上传前后 HTTP 响应 `content-length` 与像素尺寸；查主题或插件是否在入库时生成多尺寸衍生图。若衍生图从过低质量母图生成，应提高上传母图质量或关闭「先暴力压再裁」的插件顺序。
编辑上传被报「不是有效 JPG」，是渐进标记还是 CMYK/灰度模式惹祸？
老库常只认 baseline RGB JPEG；导出前转 sRGB 8-bit baseline 并去掉异常 APP 段。用 `file` 或十六进制头快速确认 SOF 类型。
文章里同一张图出现两个不同清晰度版本，是响应式 srcset 还是编辑器重复插入？
审查 HTML 是否混用全尺寸与缩略 URL；统一走媒体库引用而非粘贴外链。清理重复可显著降低带宽与 SEO 重复内容风险。
升级 PHP 的 GD 后颜色轻微漂移，要全局重导素材吗？
先抽样对比 ΔE 与业务可接受阈值；若仅边缘案例超标，可只重导高频 Banner。记录版本号以便下次升级对照。
内网要求图片无 EXIF，批量 GIF 转 JPG 怎样自动化剥离？
在导出流水线统一 `strip-all`，并在入库前做校验任务；禁止依赖编辑手动「另存为」自律。违规上传应在 CMS 层直接拒绝并提示。