手写实现狗狗照片压缩算法面试不再慌
面试被问原理答不上来，是不是特别尴尬？别慌，很多转岗的兄弟都卡在这。今天咱们不聊虚的，直接拆解狗狗照片处理中的核心逻辑，用手写实现的方式把底层搞透。
这不仅仅是图像处理，更是后端高频考点。很多候选人背了八股文，但让你现场写个简易版图片优化器就懵了。咱们今天就从最经典的 JPEG 压缩算法切入，看看那些大厂开源库里是怎么处理一张狗狗照片的。哪怕你之前没接触过，看完这篇，你也能在面试时从容不迫地讲出设计思想。
入口定位：从一张图片到字节流
很多新手觉得图片压缩就是调个库函数，比如 Python 的 Pillow 或者 Java 的 ImageIO。但在面试中，面试官问的不是“你会用吗”，而是“它是怎么做的”。
我们来看一个典型的开源项目结构。以经典的 libjpeg-turbo 为例，这是 C 语言写的，但逻辑在所有语言中通用。入口通常在一个 main 函数或者一个 compress 方法里。
这里有个坑，很多人不知道，狗狗照片这类纹理复杂的图片，和纯色背景图片的处理路径是不一样的。纹理复杂的区域，DCT（离散余弦变换）后的系数分布很均匀，压缩率低；而纯色区域，大部分系数是 0，压缩率极高。
我们看一段伪代码，这是很多框架的入口逻辑：
def process_dog_photo(image_data):# 1. 读取原始像素数据，这里假设是 RGB 格式# 注意：真实场景中，这一步涉及文件 IO 和内存映射，性能关键点之一raw_pixels = load_image(image_data)# 2. 色彩空间转换，RGB 转 YCbCr# 为什么转？因为人眼对亮度敏感，对色度不敏感# 这一步是后续降采样的前提，也是压缩率的来源y, cb, cr = rgb_to_ycc(raw_pixels)# 3. 色度降采样# 4:2:0 采样，Cb 和 Cr 的分辨率变为原来的 1/4# 这是视觉无损压缩的核心 trickcb_downsampled = downsample(cb, factor=2)cr_downsampled = downsample(cr, factor=2)# 4. 分块，8x8 块# DCT 只能处理 8x8 的矩阵，所以必须切块y_blocks = split_into_8x8(y)cb_blocks = split_into_8x8(cb_downsampled)cr_blocks = split_into_8x8(cr_downsampled)# 5. DCT 变换 + 量化 + 熵编码# 这才是真正的压缩发生的地方return encode_dct_blocks(y_blocks, cb_blocks, cr_blocks)你看，入口很简单，但每一步都有讲究。特别是第二步和第三步，这是针对狗狗照片这种自然图像优化的关键。如果你只是简单地把 RGB 直接 DCT，效果会差很多，而且面试时如果你只说“做了 DCT”，面试官会追问：“为什么不是直接对 RGB 做？”答不上来，基本就挂了。
核心片段：DCT 变换与量化矩阵
接下来是重头戏，DCT（离散余弦变换）。这是 JPEG 标准的核心。
在 CSDN 上搜“JPEG 原理”，你会发现很多文章贴了一堆公式，看得人头晕。其实核心就一句话：把空间域的信号转到频域。
在空间域，相邻像素的值变化很大，信息冗余高。在频域，能量集中在低频部分（左上角），高频部分（右下角）能量很低，甚至接近于 0。
我们看一段简化的 DCT 计算逻辑。注意，这里为了讲解清晰，我省去了大量的数学推导，直接看代码结构：
// 简化版的 8x8 DCT 变换逻辑
// 输入：一个 8x8 的像素块 block
// 输出：变换后的频域系数矩阵 dct_blockvoid fast_dct_8x8(int block[8][8], int dct_block[8][8]) {// 1. 行变换// 对每一行进行 1D DCTfor (int i = 0; i 8; i++) {for (int k = 0; k 8; k++) {float sum = 0.0;// C(k) 是归一化常数，k=0 时为 1/sqrt(2)，否则为 1float c_k = (k == 0) ? 0.7071 : 1.0;for (int j = 0; j 8; j++) {// 核心公式：余弦函数// 这里用查表法优化，避免运行时计算 cosfloat cos_val = cos_table[k][j]; sum += block[i][j] * cos_val;}temp[i][k] = c_k * sum;}}// 2. 列变换// 对每一列进行 1D DCT，得到最终的 2D DCT 系数for (int j = 0; j 8; j++) {for (int k = 0; k 8; k++) {float sum = 0.0;float c_k = (k == 0) ? 0.7071 : 1.0;for (int i = 0; i 8; i++) {float cos_val = cos_table[i][k];sum += temp[i][j] * cos_val;}dct_block[k][j] = (int)(c_k * sum + 0.5); // 取整}}
}逐行注释解析：for (int i = 0; i 8; i++): 外层循环遍历行。DCT 是分离的，可以先对行做，再对列做，这样计算量从 \(O(N^3)\) 降到 \(O(N^2)\)。
float c_k = (k == 0) ? 0.7071 : 1.0;: 这是归一化因子。很多初学者会在这里算错，导致重建图像时亮度不对。\(0.7071\) 其实是 \(1/\sqrt{2}\)。
float cos_val = cos_table[k][j];: 重点来了。在高性能实现中，绝不会在循环里调用 cos() 函数。所有的 \(\cos(k\pi/16)\) 值在程序启动时就预计算好，存进一张表里。这就是所谓的“查表法（LUT）”，是后端性能优化的基本操作。
dct_block[k][j] = (int)(c_k * sum + 0.5);: 注意这里加了 0.5 再取整。这是为了进行四舍五入，减少累积误差。如果直接 (int)sum，是截断，误差会很大。这一段代码，如果你能在白板上默写出来，并解释为什么用查表法，面试官对你的印象分会直接拉满。因为这说明你不仅懂算法，还懂工程落地。
设计思想：量化与熵编码的艺术
DCT 之后，我们得到了一组浮点数或整数。这时候，狗狗照片的细节还都在。但我们要压缩，就得丢信息。怎么丢？丢人眼看不见的。
这就是量化（Quantization）。
量化矩阵是一张 8x8 的表。JPEG 标准里定义了两种：标准量化表（质量高）和粗量化表（质量低）。
# 标准 JPEG 亮度量化表 (Y 通道)
# 注意：左上角值小，右下角值大
QUANT_TABLE = [[16, 11, 10, 16, 24, 40, 51, 61],[12, 12, 14, 19, 26, 58, 60, 55],[14, 13, 16, 24, 40, 57, 69, 56],[14, 17, 22, 29, 51, 87, 80, 62],[18, 22, 37, 56, 68, 109, 103, 77],[24, 35, 55, 64, 81, 104, 113, 92],[49, 64, 78, 87, 103, 121, 120, 101],[72, 92, 95, 98, 112, 100, 103, 99]
]def quantize(dct_coeff, quant_table, quality_scale):# quality_scale 通常由用户设定的质量参数（0-100）推导而来# 质量越高，scale 越小，量化越轻result = [[0 for _ in range(8)] for _ in range(8)]for i in range(8):for j in range(8):# 核心操作：除法取整# 注意：这里不是浮点除法，是整数除法，速度快# 但要注意负数的处理，通常用 (x + 0.5) / y 或者特殊处理q_val = quant_table[i][j] * quality_scale# 简单的整除，实际工程中需要处理负数舍入问题result[i][j] = int(dct_coeff[i][j] / q_val)return result设计思想剖析：左上角为什么值小？ 因为低频分量（直流分量，代表平均亮度）能量最大，对人眼最重要，所以量化步长要小，保留更多细节。
右下角为什么值大？ 高频分量代表纹理、边缘，能量小，人眼对高频不敏感，所以量化步长大，直接丢弃大部分信息。
为什么是除法？ 量化本质是映射。比如系数是 100，量化表值是 10，结果就是 10。如果系数是 9，结果就是 0。这就是信息丢失的地方。面试时，如果问到“为什么 JPEG 是有损压缩”，你就回答：量化过程是不可逆的。你不知道原始系数是 100 还是 109，只知道它被量化成了 10。这就是有损的本质。
手写简化版：ZigZag 扫描与 Huffman 编码
量化之后，很多系数变成了 0。怎么存？如果按顺序存，[0, 0, 1, 0, 0, 0, 5, 0...]，太浪费空间了。
这时候，手写实现的关键技巧来了：ZigZag 扫描。
把 8x8 的矩阵，按“之”字形顺序读出来。这样，大量的 0 会集中在数组的后面。
# 预定义的 ZigZag 扫描顺序索引
ZIGZAG_ORDER = [0, 1, 8, 16, 9, 2, 3, 10,17, 24, 32, 25, 18, 11, 4, 5,12, 19, 26, 33, 40, 48, 41, 34,27, 20, 13, 6, 7, 14, 21, 28,35, 42, 49, 56, 57, 50, 43, 36,29, 22, 15, 23, 30, 37, 44, 51,58, 59, 52, 45, 38, 31, 39, 46,53, 60, 61, 54, 47, 55, 62, 63
]def zigzag_scan(quantized_block):# 输入：8x8 的量化后矩阵# 输出：一维数组，0 集中在尾部flat = [0] * 64for i in range(64):# 根据预定义的顺序，从原矩阵取值row = ZIGZAG_ORDER[i] // 8col = ZIGZAG_ORDER[i] % 8flat[i] = quantized_block[row][col]return flat扫描完，我们得到 [1, 2, 0, 0, 0, 0, 5, 0, ...]。
接下来是RLE（游程编码）。我们不再存数字本身，而是存“有几个 0”和“下一个非零数是多少”。
例如：[1, 2, 0, 0, 0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0]
编码后：第一个数 1：Run=0 (前面0个0), Level=1
第二个数 2：Run=0, Level=2
第五个数 5：Run=4 (前面4个0), Level=5
结束：EOB (End of Block)最后，对这些 (Run, Level) 对进行 Huffman 编码。Huffman 树是根据统计频率构建的，出现频率高的短码，低的长码。
这就是狗狗照片能被压缩到几 KB 的完整链路。从像素到 DCT，到量化，到 ZigZag，到 RLE，到 Huffman。每一步都在减少冗余。
应用场景与避坑指南
在实际项目中，你很少需要从头手写一个 JPEG 编码器。但是，理解这个流程能帮你解决很多实际问题。
场景一：移动端图片加载优化
很多 App 在加载狗狗照片这种大尺寸图片时，会先加载一个缩略图。这个缩略图往往不是直接缩放原图，而是利用 JPEG 的渐进式扫描（Progressive JPEG）。理解 DCT 和量化，你就知道为什么渐进式图片是先模糊后清晰，而不是从左上角往右下角显示。
场景二：WebP 与 AVIF 的对比
现在 WebP 和 AVIF 很火。它们的底层也是预测 + 变换编码，但变换算法更复杂，比如用了 DST（离散正弦变换）或者 4x4 块。如果你面试被问“WebP 比 JPEG 好在哪”，你可以说：JPEG 是 8x8 块 DCT，块效应明显；WebP 支持可变块大小，且使用了更先进的熵编码（ANS 替代了 Huffman），所以同质量下体积更小。
避坑指南：不要滥用高质量参数：很多人把 JPEG 质量设成 100。这会导致文件巨大，且量化几乎不起作用，高频噪声全保留，反而可能比质量 80 的图片看起来更“脏”，因为量化噪声被放大了。
注意色彩空间转换的精度：RGB 转 YCbCr 时，如果用整数运算，误差会累积。建议中间过程用浮点，最后再转整数。
内存对齐：在 C/C++ 手写时，8x8 的块要注意内存对齐，否则 SIMD 指令加速不了。关于继续教育与转岗的思考
很多转岗的兄弟，尤其是从非计算机专业转来的，会觉得这些底层原理离自己很远。但其实，手写实现的过程，就是建立技术直觉的过程。你不需要背诵每一个量化表的数值，但你必须知道“为什么要有量化表”。
在 CSDN 等社区，你可以找到很多高质量的源码解析，但更重要的是，你要动手。拿一张自己的狗狗照片，用 Python 写一个最简单的 8x8 DCT 函数，看看变换后的系数长什么样。当你看到那个左上角亮堂堂的大数，和右下角一堆小数的对比时，你就真正懂了。
这种从“知其然”到“知其所以然”的跨越，正是面试官最想看到的。它证明你不是在背代码，而是在理解系统。
结尾互动
技术没有银弹，但原理是通用的。今天拆解的 JPEG 流程，在 HEIC、WebP 中都有影子。
你公司项目里是怎么处理图片优化的？是直接上 CDN 的自动压缩，还是自己写了服务端的图片处理 pipeline？欢迎在评论区聊聊你的实践，或者晒出你的“手写实现”代码片段，大家一起看看有没有更优雅的写法。 手写实现狗狗照片压缩算法面试不再慌
手写实现狗狗照片压缩算法面试不再慌
面试被问原理答不上来，是不是特别尴尬？别慌，很多转岗的兄弟都卡在这。今天咱们不聊虚的，直接拆解狗狗照片处理中的核心逻辑，用手写实现的方式把底层搞透。
这不仅仅是图像处理，更是后端高频考点。很多候选人背了八股文，但让你现场写个简易版图片优化器就懵了。咱们今天就从最经典的 JPEG 压缩算法切入，看看那些大厂开源库里是怎么处理一张狗狗照片的。哪怕你之前没接触过，看完这篇，你也能在面试时从容不迫地讲出设计思想。
入口定位：从一张图片到字节流
很多新手觉得图片压缩就是调个库函数，比如 Python 的 Pillow 或者 Java 的 ImageIO。但在面试中，面试官问的不是“你会用吗”，而是“它是怎么做的”。
我们来看一个典型的开源项目结构。以经典的 libjpeg-turbo 为例，这是 C 语言写的，但逻辑在所有语言中通用。入口通常在一个 main 函数或者一个 compress 方法里。
这里有个坑，很多人不知道，狗狗照片这类纹理复杂的图片，和纯色背景图片的处理路径是不一样的。纹理复杂的区域，DCT（离散余弦变换）后的系数分布很均匀，压缩率低；而纯色区域，大部分系数是 0，压缩率极高。
我们看一段伪代码，这是很多框架的入口逻辑：
def process_dog_photo(image_data):# 1. 读取原始像素数据，这里假设是 RGB 格式# 注意：真实场景中，这一步涉及文件 IO 和内存映射，性能关键点之一raw_pixels = load_image(image_data)# 2. 色彩空间转换，RGB 转 YCbCr# 为什么转？因为人眼对亮度敏感，对色度不敏感# 这一步是后续降采样的前提，也是压缩率的来源y, cb, cr = rgb_to_ycc(raw_pixels)# 3. 色度降采样# 4:2:0 采样，Cb 和 Cr 的分辨率变为原来的 1/4# 这是视觉无损压缩的核心 trickcb_downsampled = downsample(cb, factor=2)cr_downsampled = downsample(cr, factor=2)# 4. 分块，8x8 块# DCT 只能处理 8x8 的矩阵，所以必须切块y_blocks = split_into_8x8(y)cb_blocks = split_into_8x8(cb_downsampled)cr_blocks = split_into_8x8(cr_downsampled)# 5. DCT 变换 + 量化 + 熵编码# 这才是真正的压缩发生的地方return encode_dct_blocks(y_blocks, cb_blocks, cr_blocks)你看，入口很简单，但每一步都有讲究。特别是第二步和第三步，这是针对狗狗照片这种自然图像优化的关键。如果你只是简单地把 RGB 直接 DCT，效果会差很多，而且面试时如果你只说“做了 DCT”，面试官会追问：“为什么不是直接对 RGB 做？”答不上来，基本就挂了。
核心片段：DCT 变换与量化矩阵
接下来是重头戏，DCT（离散余弦变换）。这是 JPEG 标准的核心。
在 CSDN 上搜“JPEG 原理”，你会发现很多文章贴了一堆公式，看得人头晕。其实核心就一句话：把空间域的信号转到频域。
在空间域，相邻像素的值变化很大，信息冗余高。在频域，能量集中在低频部分（左上角），高频部分（右下角）能量很低，甚至接近于 0。
我们看一段简化的 DCT 计算逻辑。注意，这里为了讲解清晰，我省去了大量的数学推导，直接看代码结构：
// 简化版的 8x8 DCT 变换逻辑
// 输入：一个 8x8 的像素块 block
// 输出：变换后的频域系数矩阵 dct_blockvoid fast_dct_8x8(int block[8][8], int dct_block[8][8]) {// 1. 行变换// 对每一行进行 1D DCTfor (int i = 0; i 8; i++) {for (int k = 0; k 8; k++) {float sum = 0.0;// C(k) 是归一化常数，k=0 时为 1/sqrt(2)，否则为 1float c_k = (k == 0) ? 0.7071 : 1.0;for (int j = 0; j 8; j++) {// 核心公式：余弦函数// 这里用查表法优化，避免运行时计算 cosfloat cos_val = cos_table[k][j]; sum += block[i][j] * cos_val;}temp[i][k] = c_k * sum;}}// 2. 列变换// 对每一列进行 1D DCT，得到最终的 2D DCT 系数for (int j = 0; j 8; j++) {for (int k = 0; k 8; k++) {float sum = 0.0;float c_k = (k == 0) ? 0.7071 : 1.0;for (int i = 0; i 8; i++) {float cos_val = cos_table[i][k];sum += temp[i][j] * cos_val;}dct_block[k][j] = (int)(c_k * sum + 0.5); // 取整}}
}逐行注释解析：for (int i = 0; i 8; i++): 外层循环遍历行。DCT 是分离的，可以先对行做，再对列做，这样计算量从 \(O(N^3)\) 降到 \(O(N^2)\)。
float c_k = (k == 0) ? 0.7071 : 1.0;: 这是归一化因子。很多初学者会在这里算错，导致重建图像时亮度不对。\(0.7071\) 其实是 \(1/\sqrt{2}\)。
float cos_val = cos_table[k][j];: 重点来了。在高性能实现中，绝不会在循环里调用 cos() 函数。所有的 \(\cos(k\pi/16)\) 值在程序启动时就预计算好，存进一张表里。这就是所谓的“查表法（LUT）”，是后端性能优化的基本操作。
dct_block[k][j] = (int)(c_k * sum + 0.5);: 注意这里加了 0.5 再取整。这是为了进行四舍五入，减少累积误差。如果直接 (int)sum，是截断，误差会很大。这一段代码，如果你能在白板上默写出来，并解释为什么用查表法，面试官对你的印象分会直接拉满。因为这说明你不仅懂算法，还懂工程落地。
设计思想：量化与熵编码的艺术
DCT 之后，我们得到了一组浮点数或整数。这时候，狗狗照片的细节还都在。但我们要压缩，就得丢信息。怎么丢？丢人眼看不见的。
这就是量化（Quantization）。
量化矩阵是一张 8x8 的表。JPEG 标准里定义了两种：标准量化表（质量高）和粗量化表（质量低）。
# 标准 JPEG 亮度量化表 (Y 通道)
# 注意：左上角值小，右下角值大
QUANT_TABLE = [[16, 11, 10, 16, 24, 40, 51, 61],[12, 12, 14, 19, 26, 58, 60, 55],[14, 13, 16, 24, 40, 57, 69, 56],[14, 17, 22, 29, 51, 87, 80, 62],[18, 22, 37, 56, 68, 109, 103, 77],[24, 35, 55, 64, 81, 104, 113, 92],[49, 64, 78, 87, 103, 121, 120, 101],[72, 92, 95, 98, 112, 100, 103, 99]
]def quantize(dct_coeff, quant_table, quality_scale):# quality_scale 通常由用户设定的质量参数（0-100）推导而来# 质量越高，scale 越小，量化越轻result = [[0 for _ in range(8)] for _ in range(8)]for i in range(8):for j in range(8):# 核心操作：除法取整# 注意：这里不是浮点除法，是整数除法，速度快# 但要注意负数的处理，通常用 (x + 0.5) / y 或者特殊处理q_val = quant_table[i][j] * quality_scale# 简单的整除，实际工程中需要处理负数舍入问题result[i][j] = int(dct_coeff[i][j] / q_val)return result设计思想剖析：左上角为什么值小？ 因为低频分量（直流分量，代表平均亮度）能量最大，对人眼最重要，所以量化步长要小，保留更多细节。
右下角为什么值大？ 高频分量代表纹理、边缘，能量小，人眼对高频不敏感，所以量化步长大，直接丢弃大部分信息。
为什么是除法？ 量化本质是映射。比如系数是 100，量化表值是 10，结果就是 10。如果系数是 9，结果就是 0。这就是信息丢失的地方。面试时，如果问到“为什么 JPEG 是有损压缩”，你就回答：量化过程是不可逆的。你不知道原始系数是 100 还是 109，只知道它被量化成了 10。这就是有损的本质。
手写简化版：ZigZag 扫描与 Huffman 编码
量化之后，很多系数变成了 0。怎么存？如果按顺序存，[0, 0, 1, 0, 0, 0, 5, 0...]，太浪费空间了。
这时候，手写实现的关键技巧来了：ZigZag 扫描。
把 8x8 的矩阵，按“之”字形顺序读出来。这样，大量的 0 会集中在数组的后面。
# 预定义的 ZigZag 扫描顺序索引
ZIGZAG_ORDER = [0, 1, 8, 16, 9, 2, 3, 10,17, 24, 32, 25, 18, 11, 4, 5,12, 19, 26, 33, 40, 48, 41, 34,27, 20, 13, 6, 7, 14, 21, 28,35, 42, 49, 56, 57, 50, 43, 36,29, 22, 15, 23, 30, 37, 44, 51,58, 59, 52, 45, 38, 31, 39, 46,53, 60, 61, 54, 47, 55, 62, 63
]def zigzag_scan(quantized_block):# 输入：8x8 的量化后矩阵# 输出：一维数组，0 集中在尾部flat = [0] * 64for i in range(64):# 根据预定义的顺序，从原矩阵取值row = ZIGZAG_ORDER[i] // 8col = ZIGZAG_ORDER[i] % 8flat[i] = quantized_block[row][col]return flat扫描完，我们得到 [1, 2, 0, 0, 0, 0, 5, 0, ...]。
接下来是RLE（游程编码）。我们不再存数字本身，而是存“有几个 0”和“下一个非零数是多少”。
例如：[1, 2, 0, 0, 0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0]
编码后：第一个数 1：Run=0 (前面0个0), Level=1
第二个数 2：Run=0, Level=2
第五个数 5：Run=4 (前面4个0), Level=5
结束：EOB (End of Block)最后，对这些 (Run, Level) 对进行 Huffman 编码。Huffman 树是根据统计频率构建的，出现频率高的短码，低的长码。
这就是狗狗照片能被压缩到几 KB 的完整链路。从像素到 DCT，到量化，到 ZigZag，到 RLE，到 Huffman。每一步都在减少冗余。
应用场景与避坑指南
在实际项目中，你很少需要从头手写一个 JPEG 编码器。但是，理解这个流程能帮你解决很多实际问题。
场景一：移动端图片加载优化
很多 App 在加载狗狗照片这种大尺寸图片时，会先加载一个缩略图。这个缩略图往往不是直接缩放原图，而是利用 JPEG 的渐进式扫描（Progressive JPEG）。理解 DCT 和量化，你就知道为什么渐进式图片是先模糊后清晰，而不是从左上角往右下角显示。
场景二：WebP 与 AVIF 的对比
现在 WebP 和 AVIF 很火。它们的底层也是预测 + 变换编码，但变换算法更复杂，比如用了 DST（离散正弦变换）或者 4x4 块。如果你面试被问“WebP 比 JPEG 好在哪”，你可以说：JPEG 是 8x8 块 DCT，块效应明显；WebP 支持可变块大小，且使用了更先进的熵编码（ANS 替代了 Huffman），所以同质量下体积更小。
避坑指南：不要滥用高质量参数：很多人把 JPEG 质量设成 100。这会导致文件巨大，且量化几乎不起作用，高频噪声全保留，反而可能比质量 80 的图片看起来更“脏”，因为量化噪声被放大了。
注意色彩空间转换的精度：RGB 转 YCbCr 时，如果用整数运算，误差会累积。建议中间过程用浮点，最后再转整数。
内存对齐：在 C/C++ 手写时，8x8 的块要注意内存对齐，否则 SIMD 指令加速不了。关于继续教育与转岗的思考
很多转岗的兄弟，尤其是从非计算机专业转来的，会觉得这些底层原理离自己很远。但其实，手写实现的过程，就是建立技术直觉的过程。你不需要背诵每一个量化表的数值，但你必须知道“为什么要有量化表”。
在 CSDN 等社区，你可以找到很多高质量的源码解析，但更重要的是，你要动手。拿一张自己的狗狗照片，用 Python 写一个最简单的 8x8 DCT 函数，看看变换后的系数长什么样。当你看到那个左上角亮堂堂的大数，和右下角一堆小数的对比时，你就真正懂了。
这种从“知其然”到“知其所以然”的跨越，正是面试官最想看到的。它证明你不是在背代码，而是在理解系统。
结尾互动
技术没有银弹，但原理是通用的。今天拆解的 JPEG 流程，在 HEIC、WebP 中都有影子。
你公司项目里是怎么处理图片优化的？是直接上 CDN 的自动压缩，还是自己写了服务端的图片处理 pipeline？欢迎在评论区聊聊你的实践，或者晒出你的“手写实现”代码片段，大家一起看看有没有更优雅的写法。