图标用 iconfont 还是 SVG：目录站几百个图标该怎么选

图标是个小东西，单个看起来不值得讨论。但目录站不一样——一个分类页几十个条目卡片，每个卡片两三个图标，再加上导航、筛选、页脚，一个页面上百个图标很正常。这时候方案选错，代价就被放大了一百倍。

图片来源：网络，版权归原作者所有，侵权请联系删除

三种做法的实际差别

方案	请求与缓存	可访问性	多色与主题	主要代价
iconfont 字体图标	整包一个字体文件，可长期缓存	读屏可能念出字符码位	只能单色，靠 color 控制	字体没加载完显示方块，还会引起布局偏移
SVG sprite 雪碧图	单文件一次请求，可强缓存	能配 title 与标签	多色受限，单色用 currentColor 最稳	跨文件引用受作用域限制，多色难控制
内联 SVG	零请求，随 HTML 一起到	完全可控	每个路径都能单独上色和动画	每个图标都是 DOM 节点，多了会拖慢解析

iconfont 最麻烦的地方不是体积，是它是字体。字体是渲染阻塞资源，没加载完的时候图标要么不显示要么显示成方块，等加载完又跳一下，布局偏移就是这么来的。而且用户如果装了自定义字体（这是常见的无障碍设置），图标可能直接变成空白方块。

另外 iconfont 整包下载，你只用其中十二个图标，用户还是要把整套字库拉下来。想只打包用到的部分就得做子集化，又多一道构建步骤。

目录站该怎么搭

结论是按页面类型混用，别全站统一。三条建议：

• 首屏关键图标用内联——导航、搜索框、logo 这些，数量少，内联进去零请求、零闪烁，首屏最稳。
• 列表里的重复图标用 sprite——条目卡片上的那些小标记，数量多又都一样，走 sprite 只发一次请求，DOM 也干净。
• 长列表别硬塞内联——几十上百行的列表每行都内联几个图标，HTML 体积和解析时间都会明显上升，这类场景 sprite 更合适。

判断标准其实很朴素：这个图标在一页里会出现多少次。一两次，内联；几十次，sprite。介于两者之间，看它是不是首屏可见。

可访问性那条

图标要么对读屏有意义，要么对读屏完全透明，没有中间状态。

纯装饰的图标（条目卡片上的大部分小标记都属于这类）加上 aria-hidden 让读屏直接跳过；图标本身承载信息的（比如一个「已认证」的勾），要给可读的文本，用 title 元素或者标签配合说明文字，别让用户只听到「图形」。

iconfont 在这一项上先天吃亏：读屏软件拿到的是字符，可能念出一个莫名其妙的码位，而且你没有什么干净的办法去干预。这也是近年主流设计系统集体转向 SVG 的原因之一。

深色模式和主题切换

如果站点有深色模式，iconfont 会立刻暴露短板——它只能靠 color 控制，颜色一变所有图标一起变，没法让某个图标的描边和填充用不同颜色。

SVG 这边用 currentColor 配合 CSS 变量最省事：图标的填充色跟着文字色走，主题切换时改变量就够了，不用为每个图标写两套。需要多色的图标再单独处理。

迁移的时候注意什么

老站从 iconfont 换到 SVG 不必一次做完。先统计到底用到了哪些图标——多数站点的字体包里真正在用的不超过三成，这一步就能把范围缩下来。

然后按页面类型分批换：先把首屏和高频页面换掉，长尾页面继续用字体包，跑一段时间确认没问题再删字体文件。别一边用着字体一边又引入全套 sprite，两套并存会让视觉细节不一致，维护也更乱。

最后一件事：图标文件也要像其他静态资源一样带文件名指纹。图标改了但缓存没更新，用户看到的是半新半旧的界面，这种问题排查起来特别费时间。