位图 vs 矢量

同一个 Logo，你把它放大十倍，一个变成了满屏的马赛克方块，另一个边缘依然刀切一样锐利。它们看起来是"同一张图"，其实在计算机内部是两种完全不同的东西——一种存的是结果，一种存的是做法。搞清这个区别，你就明白了为什么设计师给你 SVG 而不是 PNG，也明白了为什么截图放大永远救不回来。

位图：一张巨大的颜色表格

位图的原理朴素到近乎粗暴：它就是一个像素矩阵。一张 1920×1080 的图片，本质上是一张有 1920 列、1080 行的表格，一共 2,073,600 个格子，每个格子里填了一个颜色值。文件里存的就是这两百多万个颜色值，按顺序排成一长串数字。

"像素矩阵"这个词听着玄，换成大白话就是一张超级大的 Excel 表：两百多万个单元格，每格里写着一个颜色编号，谁也不知道自己是谁的一部分。那一格不知道自己是猫的眼睛还是墙的阴影，它只知道"我是 #3A2F28"。这就是位图和矢量图最根本的分野——位图里没有"东西"，只有"颜色"。

再打个更贴身的比方：位图相当于一幅已经绣完的十字绣。你把它翻过来看背面，能看到两百多万个针脚，每个针脚一种线色；但你在里面找不到任何一句"这里是一只猫"的说明。绣品保存的是结果，不是做法。

如果每个像素用 R、G、B 三个通道、每个通道 8 位（0~255）来记，那一个像素占 3 个字节；再加一个透明通道 A 就是 4 个字节。所以一张 1920×1080 的未压缩图片，理论大小是 1920 × 1080 × 4 ≈ 8.3 MB。你平时下载的图片只有几百 KB，是因为所有图片格式都做了压缩——这也是各种格式差异的核心来源。

8.3 MB 这个数字放在一张普通网页图上，简单说就是"一张图顶掉两首歌"。想象一下如果网页真按未压缩来传：一个有 20 张图的商品列表页，光图片就是 166 MB，相当于让每个访客下载一整部电影才能看到你的首页。所以压缩不是优化手段，而是图片这件事能存在于互联网上的前提。

压缩这件事本身也可以用生活场景说清。无损压缩相当于收拾行李箱：衣服叠得整整齐齐、袜子塞进鞋里，箱子小了一半，但打开后一件不少。有损压缩相当于搬家时做取舍：几年没穿的旧衣服直接扔了，箱子小了八成，但扔掉的确实回不来了。后面那张格式对比表，说的就是每种格式在"叠"和"扔"这两件事上的策略差异。

位图最大的软肋，就来自"它只存结果"这个事实。图片里根本没有"这是一条直线"的概念，只有"第 300 行第 47 到 92 个格子是黑色"这种记录。当你要放大它，程序面对的是一道无解的题：原图只有 100 个格子的信息，现在要填 400 个格子，多出来的信息从哪来？只能靠猜——这个猜的过程叫插值（interpolation）。猜得再好也是猜，所以放大后必然发虚、发糊，或者出现阶梯锯齿。

"插值"这个术语翻译成人话就是"照着两边的颜色，给中间新开的格子编一个折中色"。好比一张只记了"周一 10 度、周五 20 度"的天气笔记，你要填出周三是几度——只能取个中间值 15 度。这个 15 度不是测出来的，是编出来的。编得再合理也是编的，所以位图放大永远救不回来。这也是为什么影视剧里"把监控画面放大再增强"那种桥段是纯粹的虚构：原始画面里那几个格子如果没记下车牌，放大一万倍也变不出来。

常见位图格式对比：各有各的活

位图格式的区别，几乎全在"怎么压缩"这一件事上。压缩分两大流派：无损压缩（把数据换一种更紧凑的写法，解开后和原来一模一样）和有损压缩（丢掉人眼不敏感的细节，换取小得多的体积，且丢掉的永远回不来）。

无损压缩靠的是"找重复"。说白了就是把"黑黑黑黑黑黑黑黑"改写成"黑×8"——内容一点没变，字数少了一大半。所以一张大面积纯色的截图能压得极小，而一张每个像素都不一样的风景照几乎压不动，因为找不到可以合并的重复。这就好比整理仓库：一整排同款货物可以写一张"此货 200 件"的标签，而一堆各不相同的零碎件只能一件一件登记。

逐个说清它们的性格，为了好记，不妨把它们当成一个厨房里五个各有脾气的帮手：

• PNG · 老实人无损，一根像素都不丢，支持 256 级半透明。缺点是照片类图片体积会大得离谱——因为照片里几乎没有"重复的色块"可供无损压缩利用。所以 PNG 存截图、图标、带透明的素材是王道，存风景照就是浪费。
• JPG · 照片专家有损，利用"人眼对亮度敏感、对色彩细节不敏感"的特性，把颜色信息大幅简化。照片上效果极好，但遇到文字和硬边线条就会在边缘产生一圈脏兮兮的"蚊子噪点"。所以：截图千万别存 JPG。另外 JPG 完全不支持透明，透明区域会被填成黑色或白色。
• WebP · 全能新人Google 推的格式，同时具备有损、无损、透明、动画四种能力，同画质下比 JPG 小三成左右。今天所有主流浏览器都支持它，是网页图片的默认首选。
• AVIF · 极限压缩基于视频编码 AV1 的静态图格式，压缩率目前最强，同画质能比 WebP 再小一大截。代价是编码耗时长、部分老设备和老软件打不开，所以通常配合 <picture> 做降级方案。
• GIF · 历史包袱只能存 256 种颜色，透明只有"透"和"不透"两档（所以边缘常有难看的白毛边），动图体积却比同等视频大好几倍。它今天唯一的价值是兼容性和文化惯性——技术上应当被 WebP 动图或 <video> 取代。

用 picture 元素，让浏览器自己挑格式

网页里最推荐的做法是让浏览器自己挑它能吃的那一种，前面的格式优先，不支持就往后退：

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="首页主图" width="1200" height="630">
</picture>

浏览器从上往下试：认识 AVIF 就用 AVIF，不认识就看 WebP，都不行才落到最后那个 <img>。这样新设备享受小体积，老设备也不会白屏。

这段写法的逻辑，相当于餐厅点菜时说一句："有澳龙就上澳龙，没有就波龙，都没有就来个基围虾。"你一次把三档偏好说清，服务员按顺序往下问厨房，绝不会因为第一样没有就空着手回来。这就是渐进增强的全部精神：先说最好的，但一定留好退路。

顺带说清一个高频疑问：为什么截图存成 JPG 会脏，而照片存成 JPG 就很干净？因为 JPG 干的活儿是"把画面切成 8×8 的小块，然后把每块里的细节简化成几个主要趋势"。照片里本来就没有硬边，简化了看不出来；而截图里满是刀切一样的文字边缘和一像素细线，简化之后那个"急转弯"没法用几个趋势表达，只能在边缘留下一圈忽明忽暗的杂色——就是那圈俗称"蚊子噪点"的脏东西。好比让一个只会画写意山水的画师去描一份工程图纸：山画得好，直线一定歪。

矢量：存的是"怎么画"，而不是"画成什么样"

矢量图彻底换了个思路：它不记录任何像素，而是用数学描述图形的构造方式。一个圆，它记的是"圆心在 (50, 50)，半径 40，填充红色"；一条曲线，它记的是几个控制点和一段贝塞尔曲线公式。文件里全是坐标和参数，没有一个像素。

换成大白话：矢量图存的是一份"绣花图纸"，而不是绣好的成品。图纸上写着"耳朵是一个 30 度的三角形，眼睛是半径 4 格的圆"——这些话跟布有多少格没有任何关系，所以拿到任何一块布上都能重新绣一遍，而且都是最佳效果。位图是成品，矢量是做法；成品会随着布变粗而失真，做法不会。

"贝塞尔曲线"这个名字最容易吓人，其实就是"用几个把手来拉出一条弧线"。想象一下你在案板上摆一根软面条：两头按住，中间用两根筷子往外挑一挑，面条就弯成了一条平滑的弧。那两根筷子的位置就是"控制点"，面条最终的形状完全由这几个位置决定。矢量文件里存的正是这几个位置，而不是那根面条本身。所以你想让弧线更弯，只要把筷子挪一挪，重新摆一次即可。

这带来一个近乎魔法的性质：因为它存的是公式，所以在任何尺寸下都可以现场重新算一遍、重新画一遍。放大 100 倍？把所有坐标乘 100，重新算，边缘依然是完美的数学曲线。这就是"矢量图无限缩放不失真"的全部秘密——它不是"压缩得好"，而是根本没有分辨率这个概念。

当然，屏幕本身是像素做的，最终还是得把矢量变成像素才能显示。这个"按当前尺寸现场算出像素"的动作叫栅格化。关键区别在于：位图是出厂时就栅格化好了，矢量图是每次显示时按当前需要的尺寸重新栅格化。前者一次成型无法回头，后者永远新鲜。

"栅格化"这个词，简单说就是"照着图纸真的绣一遍"。矢量图纸自己不能挂在墙上给人看，必须先在当前这块布上落针成形。好比外卖 App 里的菜单只是一行字，你要吃到嘴里，厨师还得在厨房里真的下一次锅——菜单是矢量，端上桌的那碗面是栅格化的结果。区别在于：矢量图纸每次上桌都是现做的，位图是一碗提前做好放在保温柜里的面，你要大份也只能把这碗兑水加量。

SVG：网页里的矢量标准

网页上的矢量格式叫 SVG（Scalable Vector Graphics，可缩放矢量图形）。它有个非常特殊的身份：SVG 不是二进制图片文件，它是一段 XML 文本——你能用记事本打开它、读懂它、直接改它。

这一点的分量常被低估。说白了，一个 SVG 图标就是一张写着几行字的便签，而不是一个封死的盒子。PNG 你只能整张替换，SVG 你可以进去改一个数字就换个颜色、挪个位置。这就好比手写的菜谱便签和真空包装的速食面：便签能随手划掉"辣椒两勺"改成"半勺"，速食面只能整包扔掉换一包。

<svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
  <!-- 一个圆：圆心 50,50 半径 40 -->
  <circle cx="50" cy="50" r="40" fill="#556b3d"/>
  <!-- 一条折线路径：M 移动到, L 画直线到 -->
  <path d="M30 55 L45 70 L72 38"
        stroke="#fff" stroke-width="8"
        fill="none" stroke-linecap="round"/>
</svg>

这十来行文本就是一个"绿底白勾"的对号图标，无论显示成 16px 还是 1600px 都同样锐利，而文件只有两百来个字节。两百个字节大概是一条短信的长度——一个图标的全部信息量，抵不上一句"我到楼下了"的微信。里面几个关键概念值得记住：

• viewBox定义了一个"内部坐标系"。上面写的 0 0 100 100 意思是"我这幅画的画布是 100×100 单位"。之后所有坐标都在这个虚拟单位里写，而实际显示多大由 CSS 决定——这就是缩放自由的来源。
• path 的 d 属性矢量图的核心，一串画笔指令：M 抬笔移动、L 画直线、C 画三次贝塞尔曲线、Z 闭合。复杂的插画就是一堆这样的指令。
• fill / stroke填充色和描边色。它们可以被 CSS 覆盖，也可以设成 currentColor 来自动跟随文字颜色——这是图标换色最优雅的方案。
• 可被 CSS 和 JS 操作SVG 内的每个图形都是真实的 DOM 节点，能加 class、能 hover 变色、能加过渡动画、能被脚本改坐标。位图做不到这一点。

其中 viewBox 最值得多说一句，因为它是 SVG 里唯一真正需要动脑的概念。换成大白话，viewBox 就是"图纸自己用的那把尺"。图纸上说"圆心在 50, 50"，这个 50 不是像素、不是厘米，而是"图纸单位"；而 CSS 里给它多大宽度，就等于告诉浏览器"把这把尺整体缩放到多长"。这就好比一张标着"比例 1:100"的房屋平面图——图上量出 3 厘米，实际是 3 米；你把图纸复印放大一倍，标注的比例跟着改，房子的真实尺寸一点没变。viewBox 定义比例尺，CSS 决定打印多大，两者相乘才是屏幕上的实际尺寸。

因为是 DOM，改颜色就跟改文字颜色一样简单：

/* 让图标自动跟随按钮文字颜色 */
.btn svg { width: 1em; height: 1em; fill: currentColor; }
.btn:hover { color: #a05a2c; }   /* 图标也一起变色 */

什么时候用哪种：一条清楚的分界线

判断规则其实非常简单，问自己一句话：这张图能不能用有限条几何指令描述清楚？

这句话还可以问得更土一点：你能不能用嘴把这张图给别人讲明白，让他照着画出来？"一个绿色圆圈，里面一个白色对勾"——能讲明白，那就用矢量。"我家楼下菜市场周三下午的样子"——讲不明白，只能拍照，那就用位图。能靠说明书复现的，用矢量；只能靠拍下来记录的，用位图。

• 用矢量（SVG）图标、Logo、几何插画、图表、地图轮廓、加载动画、装饰性花纹——这些都是"有明确边界的形状"，用公式描述又准又小。
• 用位图照片、写实渲染图、复杂纹理、带真实景深与噪点的画面。你没法用几十条曲线描述一片树叶上的光斑，硬要矢量化文件会比位图大得多。
• 混合场景带照片的宣传图用位图，压在上面的文字和 Logo 用矢量或直接用 HTML 文字——各取所长。

还有一个常被忽略的现实理由：矢量图不需要准备 @2x / @3x 三份。上一节讲过，位图要在高清屏上清晰，必须准备多倍图；矢量图天生适配任何像素密度，一份文件通吃所有屏幕，工程和设计的维护成本直接砍掉三分之二。

这笔账在真实项目里非常可观。一套中等规模的 App 大约有 150 个图标，用 PNG 就是 450 个文件；改一次主色调，设计师要重新导出 450 次，工程师要替换 450 个文件，还得逐个核对有没有漏。换成 SVG 就是 150 个文件，改色只要改一行 CSS。这好比一个仓库里同一款货物存了三种包装规格，每次调价都要重贴三遍标签——而换成统一规格后，一张标签就够了。

图标方案的三次进化

"怎么在界面里放图标"这个小问题，行业整整折腾了二十年，正好是位图与矢量之争的活化石。

三代方案的差别，用一个很土的比方就能串起来：第一代相当于把每道菜都提前做好装进餐盒（PNG 切图，改不了）；第二代相当于把菜谱写进一本菜单册，服务员照着念（字体图标，能缩放但只有一种颜色）；第三代相当于把每道菜的完整做法直接交给你家厨房（SVG，想改哪一步改哪一步）。行业花了二十年才走完这三步，而每一步解决的都是上一步留下的具体痛点。

SVG 复用的经典写法是把所有图标定义在页面里一次，之后到处引用。这个 symbol + use 的套路，说白了就是"图纸放在抽屉里，用的时候贴一张便签指过去"——图纸只存一份，页面上用二十次也不会把那几行路径抄二十遍。相当于办公室里那枚公章：章只有一个，锁在抽屉里，谁要盖就拿出来盖一下，没人会为了盖章再刻十九枚。

<!-- 定义一次（可以藏在页面顶部） -->
<svg style="display:none">
  <symbol id="i-check" viewBox="0 0 24 24">
    <path d="M4 13l5 5L20 7" stroke="currentColor"
          stroke-width="2" fill="none"/>
  </symbol>
</svg>

<!-- 之后任意处引用，想用几次用几次 -->
<svg class="icon"><use href="#i-check"/></svg>

一张网页上，两种图是怎么配合的

真实项目里从来不是"选位图还是选矢量"，而是同一个页面上两种图各干各的活儿。把一个典型的电商首页拆开看，分工清楚得像一间厨房里的岗位安排。

顶部那张大幅宣传图 → 位图。因为它是实拍的商品场景，有真实光影和景深，没法用几何指令描述。这里的功夫全在"选对格式、出对尺寸"：用 AVIF/WebP 打头、JPG 兜底，按显示宽度乘 DPR 出图，再配上 srcset 让手机别下载桌面版的大图。

导航栏里的搜索、购物车、用户头像图标 → 矢量。这些都是能用嘴描述清楚的形状，而且需要在 hover 时换色、在深色模式下反色。用 SVG 一份文件通吃所有屏幕密度，改色只要一行 CSS。

商品列表里的缩略图 → 位图，但要小心。最常见的错误是把 1200px 宽的原图直接塞进 200px 的位置显示。多出来的像素全部被丢弃，白白吃掉流量和解码时间。这好比点外卖只想吃一碗面，商家给你送来一整锅——多的那些不但没用，还占着桌子。正确做法是服务端生成 400px 的缩略图（200 × DPR2）。

页面上的数据图表 → 矢量。柱状图本质就是一堆矩形，折线图就是一串坐标点，用 SVG 画既清晰又能给每根柱子挂上鼠标提示。用位图截个图放上去，不但会糊，还彻底失去了交互能力。

加载中的那个转圈动画 → 矢量。它是一段圆弧加一个 CSS 旋转，SVG 里几十个字节就够。早年这个位置放的是 GIF，体积大出几十倍，边缘还有一圈白毛。

把这套分工总结成一句可以直接背下来的话：凡是"拍下来的"用位图并配好多档尺寸，凡是"画出来的"用矢量并交给 CSS 控制。这一条能挡掉实际工作里绝大多数图片相关的坑。

几条能立刻用上的实用建议

• 截图永远别存 JPG截图里全是文字和硬边框，JPG 的有损压缩会在边缘糊出一圈噪点。用 PNG 或 WebP 无损模式。
• 照片永远别存 PNG照片没有可无损压缩的重复色块，PNG 会让文件大出好几倍却看不出画质差别。用 JPG / WebP / AVIF。
• SVG 上线前先压一遍设计软件导出的 SVG 常带一堆无用的编辑器元数据、冗余小数位。用 SVGO 之类的工具清一遍，体积常能砍掉一半以上。
• 给 img 写上宽高无论位图矢量，都在标签上写明 width/height 或用 CSS 定好比例。否则图片加载完成的瞬间会把下面内容撑开，造成页面跳动。
• 别用 SVG 存照片把照片"嵌进" SVG（base64 内联）不会让它变成矢量，只是套了个壳，还额外胖了三成。矢量的能力来自几何描述，不是文件后缀。
• 图表优先 SVG折线图、柱状图本质就是线和矩形，用 SVG 渲染既清晰又能给每根柱子挂上交互事件。

一个容易混淆的点：分辨率无关 ≠ 无限精细

矢量图"无限放大不失真"说的是已有的几何信息在任何尺寸下都能精确重绘，不是"能凭空长出更多细节"。一个只用 8 条直线画成的粗糙图标，放大到墙那么大，依然是那个只有 8 条边的粗糙图标——只不过每条边都很锐利。矢量解决的是清晰度问题，不解决细节量问题。同理，把位图用工具"转成矢量"（描摹）只是让程序去猜边界并生成路径，猜错了就会变形，这不是真正的还原。

这个区别用绣花的场景说最清楚：一张只画了 8 笔的简笔猫图纸，拿到再细的布上重绣，也还是那只 8 笔的简笔猫。布变细了，那 8 条线的边缘会变得极其平滑，但猫身上不会自己长出胡须和毛发——图纸上本来就没画。矢量保证的是"图纸上有的东西都能画得干净"，不保证"图纸上没有的东西也能出现"。

反向的那个坑更值得警惕：把位图"转成矢量"这件事，本质是让程序去猜边界。好比让一个人看着一幅已经绣好的模糊猫像，去反推出原始图纸——他只能靠猜"这条边大概是条直线吧"。猜对了看着挺好，猜错了耳朵就变成了尖角。所以描摹工具适合处理黑白分明的简单图形（比如扫描的手写签名），完全不适合处理照片。矢量的能力来自"有人真的写下了几何描述"，不是来自文件后缀。

最后再点一句本节和上一节的关系：§ 2.1 讲的是"一个格子有多大"，这一节讲的是"这些格子里的内容是提前填好的，还是现场算出来的"。两节合起来就把"一张图为什么在这台机器上是糊的"这个问题彻底解释完了——要么是格子密度对不上（DPR 问题），要么是内容本来就是死的（位图问题）。下一节会往格子里再钻一层，看看一个格子里的颜色到底是怎么记下来的。