图标库

打开任何一个前端项目的图标库文件夹，翻到 `assets` 或者 `static` 目录，图标库十有八九能找到一堆 SVG 文件。图标库它们可能叫 `arrow-left.svg`、图标库`user-profile.svg`、图标库`close-btn.svg`，图标库文件名起得随意，图标库但缺了哪个，图标库页面就会在某个角落露出一个尴尬的图标库空白方块。图标库这件事，图标库表面上是图标库设计师的活儿，实际上前端开发者每天都在跟它打交道。图标库

早些年做项目，图标库图标基本靠雪碧图。图标库把所有小图标拼成一张大 PNG，图标库然后用 `background-position` 去定位。那时候改一个图标的颜色，得重新导出一张图。设计师给什么色就是什么色，前端想调个 hover 态，只能用 CSS 滤镜凑合，效果往往不尽人意。后来 iconfont 火了一阵，把图标做成字体，用 `color` 属性就能改颜色，听起来很美。但字体图标有个硬伤——它本质上是文字，渲染时会出现锯齿，尤其在低分辨率屏幕上，一个 16px 的齿轮图标能糊成一团。而且多色图标基本没戏，一个字形只能有一种填充色。

SVG 的普及改变了局面。它天生就是矢量，放大缩小不失真，每个路径都能单独上色，还能用 CSS 直接控制 `fill` 和 `stroke`。现在主流的图标库，像 Heroicons、Lucide、Phosphor，清一色提供 SVG 格式。Heroicons 分 outline 和 solid 两套，outline 用 1.5px 的描边，solid 用填充，同一个图标两种气质，切换起来很方便。Lucide 更激进，所有图标统一 24x24 网格、2px 描边、圆角端点，风格极其一致。你把它塞进任何界面里，都不会显得突兀。

但图标库用多了，也会遇到麻烦。一个中型后台系统，侧边栏、按钮、表格操作列、空状态提示，零零碎碎加起来可能用到上百个图标。如果每个都单独 import，打包体积会悄悄膨胀。Tree-shaking 能解决一部分问题，前提是你用的构建工具配置正确，而且图标库本身支持 ES module 导出。有些老牌图标库还是 CommonJS 格式，摇树摇不掉，最后打进 bundle 里的可能是一整套几千个图标。我见过一个项目，只用了五个图标，打包出来多了 300KB，查了半天才发现是图标库的锅。

另一个坑是命名混乱。同一个“关闭”动作，有的库叫 `close`，有的叫 `x`，有的叫 `times`。团队协作时，A 同学从 Heroicons 找了个 `trash`，B 同学从 Material Icons 找了个 `delete`，结果界面上两个删除按钮的视觉重量完全不一样。一个线条粗犷，一个纤细精致，并排放在表格里，像穿了不同制服的门卫。所以成熟团队通常会锁定一个主图标库，再配一套自定义补充图标，统一描边宽度、圆角半径和视觉尺寸。Figma 里建一个图标组件库，前端直接导出 SVG，命名规范也统一走 kebab-case。

说到自定义图标，有个细节容易被忽略：SVG 代码的优化。设计师从 Illustrator 导出的 SVG，往往带着一堆无用的 ``、`` 和注释，`path` 的 `d` 属性里小数点后拖了七八位。直接扔进项目里，文件体积翻倍不说，有些编辑器还会因为复杂的路径数据卡顿。用 SVGO 跑一遍，去掉冗余信息，合并路径，精度降到两位小数，一个图标能从 4KB 压到 800 字节。这个习惯值得养成，尤其是图标数量多的时候。

图标库的选择，说到底是在一致性、体积和灵活性之间找平衡。小项目直接用 CDN 引入整套图标字体，省事。中大型项目，按需引入 SVG 组件，配合构建工具做优化。至于设计系统级别的产品，自建图标库几乎是必然选择。毕竟图标是界面里最小的视觉单元，也是最容易被用户下意识感知到的细节。一个对齐不准的箭头，比一段文案的错别字更让人别扭。