同一张 JPEG 小图在 Chrome 里打开和 Windows 照片查看器、手机相册里看到的颜色与清晰度经常不一样。差异可能是整体偏黄、边缘发紫、灰蒙蒙也可能是一张 64×64 的缩略图放大后明显发糊。很多人第一反应是文件坏了或者 Chrome 的解码有问题其实问题出在 JPEG 从压缩字节变成屏幕像素这条链路上而且不止一个环节在起作用。这篇内容面向经常处理图片的前端工程师、内容平台的后端同学以及维护缩略图管线的开发者。读完以后你可以做三件事第一解释为什么同一张 JPEG 在不同环境里显示效果不同第二用一个最小测试页把差异量化出来而不是靠肉眼猜第三从编码、元数据、CSS 渲染三个层面做出跨浏览器一致的方案。在开始之前要明确JPEG 显示差异不是“哪边看错了”而是解码器、颜色管理器、缩放器和显示器的多个约定不同。你需要区分的是哪一层约定出了问题。1. 先看 JPEG 的显示链路从 YCbCr 到屏幕像素要过三道门JPEG 文件并不是像素数组它是一套经过离散余弦变换、量化和熵编码后的压缩数据。浏览器显示一张 JPEG 时至少要经过三个步骤解码出颜色分量、把颜色分量转换到显示器使用的 RGB、必要时对图像做缩放。这三个步骤分别由不同的模块完成它们也是差异的来源。1.1 JPEG 解码后并不是 RGB而是亮度和色度分量JPEG 内部使用的通常是 YCbCr 颜色空间。Y 代表亮度lumaCb 和 Cr 代表蓝色差和红色差。由于人眼对亮度变化更敏感而相邻像素的颜色差异相对不容易被察觉JPEG 压缩时可以把色度通道的分辨率降低从而节省大量空间。解码器的工作流程大致是熵解码得到量化后的 DCT 系数反量化、逆 DCT得到每一块的 Y、Cb、Cr 值把下采样的色度分量上采样回原始分辨率通过一个矩阵把 YCbCr 转换成 R、G、B。第 4 步的矩阵就是第一个坑。JPEG 标准规定了编码格式但没有强制规定 YCbCr 到底是按照 BT.601 还是 BT.709 公式转换。JFIF 早期的约定偏向 BT.601但很多现代编码器在图像内容接近高清视频时会采用或部分借鉴 BT.709 的特性。换句话说文件格式本身对“YCbCr 数字是多少RGB 应该是什么”没有做到完全封闭。这也是为什么同样一份 JPEG 字节在 A 浏览器解出来是一个 RGB 值在 B 解码器里解出来可能是另一个 RGB 值。如果你拿到的图片恰好是色彩测试图或包含大量边缘这种差异就会被放大。1.2 色度下采样让颜色分辨率先天不足色度下采样chroma subsampling用四个数字描述最常遇到的是采样格式含义亮度采样色度采样常见场景4:4:4每像素都保留全部颜色信息100%100%高质量存档、截图保存4:2:2水平减半100%50%视频采集、广播4:2:0水平和垂直都减半100%25%Web JPEG 最高频使用Web 上绝大多数的 JPEG 是 4:2:0。也就是说一张 128×128 的图亮度通道有 128×128 个样本而 Cb/Cr 通道可能只有 64×64 个样本。解码时需要用插值算法把色度通道放大回 128×128。插值算法决定了颜色过渡处的表现。简单复制邻域值会产生明显的“色块感”和边缘锯齿双线性插值会让过渡平滑但可能“发肉”高质量样条插值比较锐利但有时会在高对比边缘产生轻微的颜色过冲。不同浏览器、不同图形库用的上采样算法并不一致因此在文字边缘、图标边界和彩色条纹区域你会看到差异。对“小