图片压缩深度指南：Canvas API、格式选型与质量权衡

浏览器端图片压缩的核心原理

图片压缩的本质是用更少的字节表示相同的视觉信息。浏览器端压缩不依赖服务器，全部通过 Canvas API 在本地完成，既保护隐私又节省带宽。

配套工具：图片压缩工具

Canvas API 压缩流程

整个压缩过程分为三步：

1. 解码：浏览器将图片文件（PNG/JPEG/WebP）解码为内存中的位图数据
2. 绘制：将位图绘制到 Canvas 画布上，可选缩放尺寸
3. 编码：调用 canvas.toBlob() 以目标格式重新编码，输出压缩后的二进制数据

const canvas = document.createElement('canvas');
canvas.width = targetWidth;
canvas.height = targetHeight;
const ctx = canvas.getContext('2d');
// JPEG 不支持透明：先填白色背景
if (format === 'image/jpeg') {
  ctx.fillStyle = '#ffffff';
  ctx.fillRect(0, 0, canvas.width, canvas.height);
}
ctx.drawImage(img, 0, 0, targetWidth, targetHeight);
// quality 参数仅对有损格式生效，PNG 无损忽略
canvas.toBlob(blob => { /* 压缩结果 */ }, format, quality / 100);

toBlob vs toDataURL

两者都能输出压缩结果，但 toBlob() 更优：

• toBlob：直接输出 Blob 二进制对象，无需 Base64 编码，内存开销小
• toDataURL：输出 data:image/...;base64,... 字符串，Base64 编码使体积膨胀约 33%

对于大图片（几 MB），toDataURL 的 Base64 字符串可能占用大量内存，且下载时还需解码回二进制。toBlob 直接生成 Blob，可用 URL.createObjectURL() 创建本地预览 URL，下载也直接从二进制流写入，性能更优。

三种格式特性对比

JPEG：有损压缩的鼻祖

JPEG 是最老牌的有损图片格式，采用离散余弦变换（DCT）将图像分块压缩。

• 优点：兼容性最好（所有浏览器、老旧设备均支持）、压缩率高、适合照片类自然图像
• 缺点：不支持透明通道、有损压缩会产生块状伪影、文字与锐利边缘容易模糊
• 适用：照片、渐变色彩丰富的自然图像、不需要透明背景的场景

PNG：无损压缩的标准

PNG 采用 DEFLATE 无损压缩算法，不会丢失任何图像信息。

• 优点：无损压缩（画质完全保留）、支持 Alpha 透明通道、支持 8 位调色板与 24 位真彩色
• 缺点：体积通常大于 JPEG/WebP、不适合照片类图像（压缩率低）
• 适用：图标、UI 截图、线条图、需要透明背景的图片、文字截图

WebP：现代格式的新选择

WebP 由 Google 开发，同时支持有损与无损压缩，是综合最优的格式。

• 优点：有损模式下体积比 JPEG 小 25-35%、无损模式下比 PNG 小 26%、支持透明通道、支持动画
• 缺点：老旧浏览器不支持（IE 全系列、Safari 14 之前）、编码速度略慢于 JPEG
• 适用：现代网站的图片优化、追求极致体积的场景、需要透明又有体积要求的图片

选型决策树

场景	推荐格式	理由
照片、自然图像	WebP	体积最小，现代浏览器全支持
图标、截图、透明图片	PNG	无损保真，支持透明
兼容老旧设备	JPEG	兼容性最好
追求极致体积	WebP（有损 60-70）	压缩率最高
文字截图、线条图	PNG	避免有损伪影导致文字模糊

质量参数与视觉质量

质量参数的含义

canvas.toBlob() 的第三个参数 quality 取值 0-1，控制有损格式（JPEG/WebP）的压缩质量：

• 90-100：高质量，肉眼几乎无法察觉画质损失，体积约为原图的 60-80%
• 80-90：网页展示推荐区间，画质与体积的最佳平衡点
• 60-80：追求极致体积，适合缩略图、预览图等非关键场景
• 低于 50：画质损失明显，可能出现块状伪影、色彩断层

有损 vs 无损的本质差异

有损压缩（JPEG/WebP lossy）通过丢弃人眼不敏感的高频信息减小体积。人眼对亮度变化敏感、对色彩变化不敏感，因此有损压缩优先保留亮度信息、压缩色彩信息（色度子采样）。

无损压缩（PNG/WebP lossless）不丢弃任何信息，通过更高效的编码算法（如 DEFLATE 的 LZ77 + Huffman）消除数据冗余。就像 ZIP 压缩文件一样，解压后数据与原始数据完全一致。

为什么压缩后体积可能变大？

两种常见情况：

1. 原图已是高压缩率格式：如原图已是 WebP，再次用 WebP 编码时，解码→再编码的过程会引入额外开销（文件头、元数据），可能超过压缩收益
2. 原图尺寸较小：小图片（<10KB）的文件头与元数据占比高，重新编码的固定开销可能超过压缩收益

此时建议保持原格式，或尝试更低的压缩质量参数。

等比缩放算法

缩放策略

图片压缩工具的”最大宽度/最大高度”选项采用等比缩放策略：

1. 优先按最大宽度缩放：若原图宽度超过限制，按比例缩小
2. 再按最大高度缩放：若缩放后高度仍超过限制，继续按比例缩小
3. 两个限制同时存在时取更严格的限制
4. 不放大：若原图尺寸小于限制，保持原尺寸

function computeTargetSize(srcW, srcH, maxWidth, maxHeight) {
  let width = srcW, height = srcH;
  if (maxWidth > 0 && width > maxWidth) {
    height = Math.round(height * maxWidth / width);
    width = maxWidth;
  }
  if (maxHeight > 0 && height > maxHeight) {
    width = Math.round(width * maxHeight / height);
    height = maxHeight;
  }
  return { width, height };
}

缩放对体积的影响

尺寸缩放是减少图片体积的最有效手段之一。图片像素数与体积大致呈线性关系：

• 4000×3000（1200 万像素）→ 1920×1080（200 万像素）：像素数减少 83%，体积通常减少 70-85%
• 单纯降低质量参数（如 90→60）：体积可能减少 30-50%

因此，对于网页图片，先缩放到合适尺寸再压缩的效果最好。例如博客配图通常不需要超过 1920×1080，先缩放再压缩能获得最佳体积收益。

Canvas 缩放的插值质量

ctx.drawImage() 在缩放绘制时，浏览器会自动进行插值处理。默认使用双线性插值，对大多数场景质量足够。

高质量缩放技巧

若需要更高质量的缩放（如放大图片或对画质要求极高），可采用以下技巧：

1. 多步缩放：将大图分多次逐步缩小，每次缩小 50%，比一次性缩小质量更好
2. imageSmoothingQuality：设置 ctx.imageSmoothingQuality = 'high'（Chrome 支持，部分浏览器忽略）

// 多步缩放示例：4000→1920 分两步 4000→2000→1920
ctx.imageSmoothingQuality = 'high';
let curW = srcWidth, curH = srcHeight;
while (curW > targetWidth * 2) {
  curW = Math.floor(curW / 2);
  curH = Math.floor(curH / 2);
  canvas.width = curW;
  canvas.height = curH;
  ctx.drawImage(sourceCanvas, 0, 0, curW, curH);
  sourceCanvas = canvas;
}

本工具采用默认的单步缩放，对网页图片场景质量足够。多步缩放适用于对画质极致要求的场景（如摄影作品展示）。

ObjectURL vs DataURL 的内存管理

ObjectURL 的优势

URL.createObjectURL(blob) 创建一个指向 Blob 对象的本地 URL，无需将二进制数据编码为 Base64 字符串：

• 内存开销小：Blob 直接引用内存中的二进制数据，URL 仅是引用句柄
• 性能优：无需 Base64 编码/解码，直接用于 <img src> 预览与 <a download> 下载
• 适合大文件：几 MB 的图片用 DataURL 会使字符串长达数百万字符，ObjectURL 则无此问题

内存泄漏防护

ObjectURL 创建后会一直占用内存，直到被显式释放或页面卸载。正确做法是在不再需要时调用 URL.revokeObjectURL(url)：

// 替换图片时释放旧 URL
if (oldSource) URL.revokeObjectURL(oldSource.url);
if (oldResult) URL.revokeObjectURL(oldResult.url);
// 设置新图片
setSource(newSource);

本工具在以下场景释放 ObjectURL：

• 用户更换图片时释放旧图 URL
• 压缩配置变化重新压缩时释放旧结果 URL
• 组件卸载时释放所有 URL
• 重置时释放所有 URL

实际应用场景

博客图片优化

博客配图通常需要：① 缩放到内容区域宽度（如 800-1200px）；② 压缩到网页展示质量（80-85）；③ 转换为 WebP 格式。一张 4000×3000 的 8MB 照片，经此流程可压缩到 200-400KB，体积减少 95% 以上。

网页性能优化

网页 LCP（最大内容绘制）指标受图片加载影响极大。将首屏图片压缩并转换为 WebP 格式，可显著提升 Lighthouse 性能评分。配合 <picture> 标签与 loading="lazy" 实现最优加载策略。

邮件附件压缩

部分邮件服务商限制附件大小（如 25MB）。将高分辨率照片压缩到适当尺寸与质量，可在不损失可读性的前提下满足附件大小限制。

存储空间节省

云存储服务（如 iCloud、Google Photos）会对图片进行压缩以节省空间。本地压缩可在上传前完成，减少上传带宽消耗与云端存储费用。

与 Base64 图片互转工具的配合

本站的 Base64 图片互转工具 与图片压缩工具形成完整的图片处理工具链：

1. 压缩工具：减小图片体积（Canvas API → toBlob）
2. Base64 工具：将压缩后的图片转为 Data URL 嵌入 HTML/CSS

典型工作流：上传原图 → 压缩到合适尺寸与质量 → 下载压缩图 → 在 Base64 工具中转为 Data URL → 嵌入到 HTML/CSS 中作为内联图片。

两者均采用纯前端 Canvas API 实现，零上传零追踪，适合处理敏感图片（如含个人信息的截图）。

与图片格式转换工具的配合

压缩前常需要先切换图片编码格式，再针对目标格式做质量参数扫描。本站的压缩前格式转换器支持 PNG / JPEG / WebP / AVIF / BMP / GIF 互转，与压缩工具形成”格式决策 → 质量调优”两阶段工作流：

源格式	推荐目标格式	原因
PNG（含透明）	WebP	保留透明通道 + 更高压缩率
BMP / TIFF	JPEG / WebP	移除未压缩格式，体积骤降
JPEG（无透明）	WebP	同质量下体积再降 25-35%
HEIC（苹果生态）	JPEG / WebP	提升跨浏览器兼容性

格式转换后再用压缩工具按目标格式做质量参数扫描，可获得最优体积-画质平衡点。

性能与体积考量

压缩耗时

Canvas 压缩的耗时主要取决于图片尺寸与格式：

• 1000×1000 以下的图片：通常 < 50ms
• 4000×3000 的大图：可能需要 200-500ms
• WebP 编码比 JPEG 略慢（约 1.2-1.5 倍），但体积收益更大

本工具采用 200ms 防抖，用户拖动质量滑块时避免每次微调都触发压缩，平衡响应性与性能。

浏览器兼容性

• Canvas API：所有现代浏览器均支持，IE9+ 也支持
• WebP 编码：Chrome 17+、Firefox 96+、Safari 16+、Edge 79+ 支持 toBlob 输出 WebP
• toBlob：IE10+ 支持，所有现代浏览器均支持

若浏览器不支持 WebP 编码，toBlob 会返回 null，本工具会提示”压缩失败，目标格式可能不被当前浏览器支持”。建议使用 Chrome/Edge/Firefox 最新版本获得最佳体验。

协同工作流

图片压缩通常不是孤立操作，而是图像处理工作流的一环：

• 压缩前尺寸归一化：先用压缩前尺寸归一化工具将原图缩放到目标展示尺寸（如 1920×1080），再压缩可显著降低编码耗时与内存占用
• 防盗图水印批量添加器：压缩前先用防盗图水印批量添加器添加版权水印，避免压缩后水印画质损失