图标方案怎么选：SVG图标、字体图标还是图片

星图导航配图

三种方案的真实成本

图片图标，也就是一个个 png 或者 webp 文件。优点是简单，任何场景都能用，传上去改个路径就行。缺点是每个图标都是一次独立请求，一个页面二十个图标就是二十次请求，HTTP2 下虽有改善，但总量还是大；另外尺寸固定，高清屏会糊。

字体图标，把图标做成字体文件，用文字的方式调用。优点是矢量、可换色、体积小、一次请求加载一整套。缺点也明显：只能单色，做不了多色图标；字形渲染有细微差异，偶尔会有锯齿；无障碍上如果不加 aria 处理，读屏软件会念出乱码。

SVG 雪碧图，把所有 SVG 塞进一个文件，用 symbol 引用。优点是矢量、支持多色、一次请求、可按需改色、可加动画。缺点是要处理兼容性和构建流程，图标多了文件会变大，得按需拆分。

导航站的特点是图标多，一个首页可能展示几十到上百个站点图标，而且每个图标都不一样、都是外站 favicon 抓下来的位图，不是自己设计的。

这种场景下，SVG 方案基本用不上，因为抓来的是位图，转 SVG 不现实。现实做法是把位图统一处理：统一尺寸，比如 64 乘 64 或者 128 乘 128，统一格式，优先 WebP，文件名用站点 id，走同一个目录。

请求数量的问题用雪碧图或者字体解决不了位图，只能靠缓存和 CDN。给图标目录设长缓存，文件名带版本，再开 HTTP2，几十个图标就能并发拿到，实际感知很快。

如果图标数量特别大，可以考虑延迟加载：首屏可见的图标立即加载，屏幕外的等滚动到再加载。导航站首页动辄上百图标，这一条能明显减首屏压力。

统一尺寸能省一半麻烦。不同站点抓来的 favicon 大小五花八门，有 16 乘 16 的、有 512 乘 512 的、有长条形的。入库前统一缩放到正方形，居中留白，前台排版才不会高低不齐。

透明底要处理。很多 favicon 是透明底，放在白色卡片上没问题，放在深色主题上就看不清。做法是给图标容器加一个浅色圆角背景，让透明图标也有依托。

兜底图必须有。抓不到 favicon 的站点很常见，一定要有默认图，别让前台出现破图。更别用第三方抓取服务的默认图，那种图所有站都一样，一眼假。

图标和站名要对齐。图标高度和文字行高对不上，视觉上就是歪的。统一容器高度、图标垂直居中，这属于排版基本功。

抓 favicon 抓成通用图。有些抓取接口在失败时返回同一张默认图，几百个站点配的是同一张，肉眼一看就知道没抓到。判断方法是比对文件字节数，多张图字节数完全一样，基本就是兜底图。

SVG 图标直接当位图用。有些站点的 favicon 是 SVG，直接塞进 img 标签在老浏览器上不显示，需要先渲染成位图再用。

图标文件名和数据库 id 不一致。上传时按站点名命名，入库时按 id 记录，结果前台拼路径拼不到。最稳的做法是文件名直接用 id，入库只存相对路径，改站名也不影响。

最后一句建议：图标这件事，用户不会专门夸你，但一旦有破图、糊图、错图，整个站的质感就下去了。花半天把图标统一处理一遍，比多写十篇文章的体感提升更直接。

图标目录单独设一条 nginx 规则，给一年的缓存时间，加 immutable 标记。这样浏览器第一次拿到就不再回源，回访用户的图标请求成本接近零。

图标文件本身要小。128 乘 128 的 WebP 图标通常在 2 到 8KB，如果超过 15KB，说明尺寸太大或者质量参数太高，压一遍再传。

别把图标和页面图片混在一个目录。混在一起没法给图标单独设缓存策略，也没法单独做 CDN 规则。目录分开，规则才能分开。

图标数量超过五十个的时候，考虑分页或者分类展示。一次渲染上百个图标，就算有缓存，首次访问的请求数也很可观。用户其实不需要一次看到全部。