别再只压一次图：把图片压缩接入上传、存储与发布链路

很多项目第一次处理图片体积问题时，采用的方案都很直接：运营上传图片，开发发现文件太大，再临时找工具压缩一次，然后重新上传。

这个方法能解决眼前的问题，却很难解决下一次问题。只要上传入口没有约束，几天后仍然会出现 8MB 的文章头图、4000px 的商品缩略图，或者被重复压缩多次、已经无法恢复细节的 JPEG。

真正稳定的 image compress 流程，不应该是发布前的一次人工操作，而应该贯穿以下几个环节：

选择文件
  ↓
浏览器预检与生成候选版本
  ↓
服务端重新校验
  ↓
保存原图与派生图
  ↓
发布前质量闸门
  ↓
按场景交付正确版本

本文不讨论“把质量参数调到多少最好”，而是从工程角度搭建一条可重复、可验证、可以回滚的图片处理链路。

一、先把“合格图片”写成契约

“图片尽量小”不是一个可以执行的规则。不同图片承担的任务不同，约束也应该不同。

例如，文章封面、用户头像和产品详情图可以分别定义处理档位：

这里的数值只是配置示例，不是适用于所有项目的标准。实际预算应根据页面布局、目标设备、图片内容和业务对画质的要求确定。

一个比较完整的图片契约至少应该包含：

• 允许上传的文件类型；
• 输入文件的最大体积；
• 输出图片的最大宽高；
• 是否允许转换格式；
• 输出体积预算；
• 必须保留的能力，例如透明背景或动画；
• 超出预算时是拒绝上传、进入人工检查，还是继续发布并记录告警。

当这些规则只存在于聊天记录里时，它们无法被稳定执行。更好的做法是把它们写进配置，让前端、服务端和构建流程读取同一份定义。

export const imageProfiles = {
  avatar: {
    maxEdge: 512,
    maxBytes: 150 * 1024,
    format: "image/webp",
    quality: 0.82,
  },
  articleCover: {
    maxEdge: 1600,
    maxBytes: 350 * 1024,
    format: "image/webp",
    quality: 0.84,
  },
  articleContent: {
    maxEdge: 1200,
    maxBytes: 300 * 1024,
    format: "image/webp",
    quality: 0.86,
  },
};

二、浏览器预处理的目标不是“替代服务端”

在浏览器里先缩放和压缩图片，可以减少上传等待时间，也能让用户在提交前看到候选结果。但前端环境由用户控制，因此前端检查不能作为最终安全边界。

浏览器预处理适合完成三件事：

1. 尽早发现格式或体积不符合要求的文件；
2. 生成适合当前场景的上传候选图；
3. 显示处理前后的尺寸、体积和预览，让用户决定是否接受。

下面是一个简化示例。它使用 createImageBitmap 解码图片，通过 Canvas 调整尺寸，再导出 WebP 候选文件：

async function prepareImage(file, profile) {
  if (!file.type.startsWith("image/")) {
    throw new Error("请选择图片文件");
  }

  // 动图、SVG 和特殊格式需要独立处理，不能直接套用此流程。
  const excludedTypes = ["image/gif", "image/svg+xml"];
  if (excludedTypes.includes(file.type)) {
    throw new Error(`当前流程不处理 ${file.type}`);
  }

  const bitmap = await createImageBitmap(file);
  const scale = Math.min(1, profile.maxEdge / Math.max(bitmap.width, bitmap.height));
  const width = Math.max(1, Math.round(bitmap.width * scale));
  const height = Math.max(1, Math.round(bitmap.height * scale));

  const canvas = document.createElement("canvas");
  canvas.width = width;
  canvas.height = height;

  const ctx = canvas.getContext("2d", { alpha: true });
  if (!ctx) {
    bitmap.close();
    throw new Error("无法创建 Canvas 上下文");
  }

  ctx.drawImage(bitmap, 0, 0, width, height);
  bitmap.close();

  const blob = await new Promise((resolve, reject) => {
    canvas.toBlob(
      value => value ? resolve(value) : reject(new Error("图片导出失败")),
      profile.format,
      profile.quality,
    );
  });

  return {
    blob,
    width,
    height,
    originalBytes: file.size,
    outputBytes: blob.size,
    withinBudget: blob.size <= profile.maxBytes,
  };
}

调用后，不要只显示“压缩成功”，而应该把关键结果告诉用户：

const result = await prepareImage(file, imageProfiles.articleCover);

console.table({
  原始体积: file.size,
  输出体积: result.outputBytes,
  输出尺寸: `${result.width} × ${result.height}`,
  是否达标: result.withinBudget,
});

如果结果没有达到体积预算，不建议在浏览器里自动循环降低质量，直到数字变绿。自动重试可能让截图文字或产品细节在用户不知情的情况下变得模糊。更稳妥的做法是提供两个候选档位，并要求用户预览后选择。

三、前端已经压缩，服务端为什么还要检查？

因为请求可以绕过前端，也因为浏览器提供的文件名和 MIME 类型不能证明文件内容一定符合预期。

服务端收到图片后，至少应该重新确认：

• 文件是否能够被图片解码器正常解析；
• 实际格式是否在白名单内；
• 宽高和总像素数是否超过限制；
• 文件体积是否符合上传入口的上限；
• 动图帧数是否异常；
• 解码过程是否消耗过多内存或时间。

前端负责改善体验，服务端负责维护边界。两者不是重复劳动，而是处理不同层面的风险。

接口返回值也应该包含可观测信息，而不是只有一个 URL：

{
  "assetId": "img_01J...",
  "source": {
    "width": 4032,
    "height": 3024,
    "bytes": 4821931,
    "format": "jpeg"
  },
  "variant": {
    "name": "article-cover",
    "width": 1600,
    "height": 1200,
    "bytes": 287420,
    "format": "webp"
  },
  "status": "ready"
}

这样前端、日志系统和后台管理页面都能明确知道：保存的是哪个原始资源，生成了什么版本，最终交付文件是否满足约束。

四、原图和派生图必须分开管理

图片链路里最难补救的问题，通常不是某个文件太大，而是团队已经不知道哪个文件才是原图。

如果每次修改都以上一次的压缩结果为输入，图片会经历重复编码。一次处理看不出明显区别，多次处理后，文字边缘、渐变和细小纹理就可能逐渐损坏。

建议把资源分为两类：

• Master：未经重复压缩的原始文件，用于归档和重新生成；
• Variant：针对头像、封面、缩略图等用途生成的派生版本。

派生文件的存储 Key 可以由“原图哈希 + 处理规格版本”生成：

assets/{sourceHash}/v3/article-cover-1600.webp
assets/{sourceHash}/v3/article-content-1200.webp
assets/{sourceHash}/v3/thumbnail-400.webp

这样做有三个好处：

1. 相同原图与相同配置可以复用结果；
2. 修改压缩策略时，通过升级 v3 到 v4 重新生成，而不覆盖旧版本；
3. 发现画质问题时，可以快速回滚到上一套规格。

这也是幂等处理的基础：同一个原图和同一份配置，无论任务执行多少次，都应该指向相同的派生资源，而不是继续压缩已有结果。

五、质量闸门不能只有文件体积

自动化系统容易检查字节数，却很难理解一张图为什么重要。

因此，图片发布可以分成两层验收。

自动检查

• 格式、尺寸和体积是否符合配置；
• 图片能否正常解码；
• 宽高比是否出现异常变化；
• 透明通道或动画是否被意外丢失；
• 派生图是否来自 Master，而不是另一个 Variant。

人工抽检

• UI 截图中的小字是否清晰；
• 人脸和头发边缘是否自然；
• 商品材质与颜色是否失真；
• 天空、阴影等渐变区域是否出现色带；
• 图片在真实页面和移动端尺寸下是否正常。

这里需要特别注意“100% 缩放”的误区。图片最终可能只在 360px 宽的手机卡片里出现，也可能在桌面端占据整个首屏。检查时应该覆盖真实使用尺寸，而不是只在图片查看器里无限放大寻找差异。

六、少量临时图片不一定要接入完整流水线

工程化并不意味着所有场景都必须搭建服务。一次性活动页、少量博客配图或临时分享文件，可以先用浏览器工具生成候选版本。

例如，ImageCompress 可以用于处理少量可公开图片，再比较处理前后的体积和显示效果。涉及用户资料、内部设计稿、证件、合同或未发布产品时，应先确认文件处理与保存规则，必要时改用本地工具或团队批准的服务。

无论使用在线工具还是自动化脚本，都应该遵守同一条原则：保留原图，只从原图生成发布副本，不要拿压缩后的文件继续压缩。

七、让压缩结果进入监控，而不是停留在上传页

如果项目已经有大量图片，可以记录以下指标：

• 每种业务场景的输入体积与输出体积；
• 图片处理成功率与平均耗时；
• 超出预算的资源数量；
• 各页面图片总传输量；
• 最常触发人工复核的图片类型；
• 不同规格版本的命中率。

这些数据可以回答一些比“平均压缩率是多少”更有价值的问题：

• 哪个上传入口最常产生超大图片？
• 哪类资源的体积预算设置得不合理？
• 新策略是否真的改善了线上传输，而不是只让存储里的文件变小？
• 是否有页面仍然在引用 Master，而没有使用 Variant？

压缩率只是处理结果，页面实际加载的资源才是交付结果。

发布前检查清单

• 每个上传场景都有明确的图片配置；
• 前端预处理失败时有清楚的错误提示；
• 服务端会重新验证真实文件内容；
• Master 与 Variant 分开保存；
• 派生资源名称包含规格版本；
• 同一任务重复执行不会再次损伤图片；
• 自动检查覆盖尺寸、体积、格式与解码；
• 关键图片经过真实显示尺寸下的人工检查；
• 页面引用的是正确的派生版本；
• 可以从原图重新生成并回滚旧规格。

总结

图片压缩真正容易失控的地方，不是某个质量参数选错，而是整个流程没有区分原图与发布版本，也没有明确谁负责校验、谁负责验收。

一条可靠的处理链路应该做到：

配置定义约束
→ 浏览器生成候选图
→ 服务端重新验证
→ 原图与派生图分离
→ 自动检查加人工抽检
→ 按实际场景交付

当这些步骤能够被重复执行、记录和回滚时，图片压缩才不再是上线前的临时补救，而会成为稳定的资源发布能力。

与其继续寻找一个适用于所有图片的“最佳压缩率”，不如先把项目中最常见的三个图片场景写成配置，再让前端、服务端和发布流程围绕同一份契约工作。

本作品采用《CC 协议》，转载必须注明作者和本文链接