从雪碧图到iconfont再到svg组件：图标方案演变

图标方案走到今天已经有了明确答案：新项目默认选 SVG（内联 symbol 或构建期按需引入），iconfont 退居兼容与过渡位置，CSS 雪碧图只在维护老项目时还有存在价值。这条演变主线不是「谁更高级」，而是评价标准从「省 HTTP 请求」换成了「渲染可控、按需加载、样式可继承」。

雪碧图：为 HTTP/1.1 的请求数而生

结论：雪碧图（CSS Sprite，把多张小图拼成一张大图，用 background-position 定位裁切）解决的是 HTTP/1.1 下并发请求受限的问题，HTTP/2 多路复用普及后，它的核心收益基本归零。

典型写法是把图标拼成 32×32 网格，然后：

.icon-edit { background: url(sprite.png) no-repeat -64px -32px; width:32px; height:32px; }

它有三个绕不开的痛点：改一个图标就得重出整张图，容易牵动其他图标；颜色写死在像素里，想换色只能再导一份彩色版或者用工具重出；高分屏要额外处理，得准备 @2x 图并配 background-size 缩放。另外定位偏移靠手算或工具生成，维护成本随图标数量线性上涨。

结论：雪碧图今天的最佳实践是「不新增、只维护」——老项目继续用，顺手把定位脚本和 @2x 规则记清楚，不要为了技术时髦做无收益迁移。

iconfont：把图标变成字体

结论：iconfont 用字体字形渲染图标，一次性解决了「任意缩放不失真」和「用 color 改色」两个问题，但把成本转移到了字体加载和语义上。

落地方式有两种。一是传统字体方案：在 iconfont 平台生成 ttf/woff2 加一份 CSS，用伪元素写 Unicode 码位引用：

@font-face { font-family:'icon'; src:url('icon.woff2') format('woff2'); font-display:swap; }
.icon-edit::before { font-family:'icon'; content:'\e600'; }

二是「symbol 版」：平台同时输出一份内联 SVG symbol 合集，用 <svg><use href="#icon-edit"/></svg> 引用——这其实已经是 SVG 方案了。

必须注意四点：字体加载有窗口期，font-display: swap 之前可能出现方块或空白，最坏情况是加载失败显示成乱码私用区字符；只支持单色，多色图标必须回到 SVG；可访问性要求图标加 aria-hidden="true"，纯装饰不该被读屏播报；存在被拦截的可能，部分安全软件或广告过滤规则会把图标字体当作可疑字体资源，导致全站图标消失——这是线上事故里最常见的 iconfont 翻车原因。

SVG 组件：当前的默认答案

结论：SVG 是目前唯一同时满足「单色可变色、多色可保留、无额外请求、可动画、可访问」的方案，有构建步骤的项目应当直接采用。

三种落地形态按项目复杂度选：

1. 内联 symbol sprite：页面头部注入一份 <svg style="display:none"> 合集，内部各 <symbol id="icon-x" viewBox="0 0 24 24">，引用处 <svg class="icon"><use href="#icon-x"/></svg>。优点是零额外请求、fill="currentColor" 自动跟随文字颜色。
2. 构建期按需引入：用 svgr 把 .svg 编译成组件，或用 vite-plugin-svg-icons 一类插件自动生成 symbol 并支持按需注入。图标多了以后，这一步是避免「首屏塞进 200 个图标」的关键。
3. 直接用图标库：lucide、react-icons、iconify 这类库本身支持 tree-shaking，按需引一个是一个，适合图标需求通用的项目。

关键参数就几个：viewBox="0 0 24 24" 保证等比缩放，currentColor 承载颜色继承，尺寸用 width/height 或 font-size: 16px; width:1em; height:1em。注意 <use> 引用外部 svg 文件在部分旧浏览器有兼容问题，所以生产环境更推荐构建期内联，而不是运行时去 fetch 一个 sprite 文件。

怎么选：两问决策法

结论：问自己「有没有构建步骤」和「图标要不要多色」，两问就能定方案。

有构建工具、需要多色或需要跟随主题色 → SVG 组件，这是默认选项。没有构建步骤的场景（例如无框架、改完即生效的轻量系统，或纯静态页）→ 内联 symbol 或继续用 iconfont 都是稳妥选择，别为了用 SVG 组件强行引入一条编译链。维护存量项目 → 保留雪碧图，新图标走新方案，灰度共存即可。

迁移时不要一次性全量替换，风险和工作量都不划算。可行的节奏是：新图标一律走 SVG，老图标改动时顺手替换，等比例自然收敛。

一句话收束：雪碧图优化的是网络，iconfont 优化的是样式，SVG 优化的是组件化能力——需求变了，赢家自然变了。