图标系统设计:打造能撑过 50 个符号的图标体系

大多数产品的图标库都会腐烂。第一位设计师交付了一套干净利落的四十个符号。第二位设计师需要再加三个,于是用错误的描边粗细徒手描了出来。第三位设计师在某个周五为了赶一个功能,直接从免费图标包里下载了一堆。到产品的第二年,每个界面上的图标列读起来就像四个不同的品牌被缝进了同一个导航里。

这篇文章是可落地的版本。网格、描边粗细、视觉校正、命名、治理,以及让图标系统在超过 50 个符号后依然保持一致的那一小套规则。没有每周图标展示,没有假装是系统的模板,只有让真实图标库在真实团队里活下来的那些决策。

图标系统到底是什么

**图标系统是一组由共同规则约束的象形符号。**包括网格尺寸、描边粗细、圆角半径、视觉对齐、命名,以及新增图标的流程。目标不是一个装满 SVG 的文件夹。目标是一个任何设计师或工程师都能扩展、而不会破坏产品视觉节奏的系统。

一堆图标不是系统。一个有 200 个符号却没有规则的 Figma 文件不是系统。系统有约束、有被命名的决策,还有一套书面流程,说明当有人需要一个尚不存在的图标时该怎么办。

设计系统指南讲的是图标所处的更大的系统。本文专门深入图标这一层。

为什么图标比看上去更重要

图标是任何产品里密度最高的 UI 元素。一个 24x24 像素的图标,每平方英寸承载的含义比屏幕上任何其他元素都多。系统做对了,产品读起来是一个整体。做错了,每个界面都会有一种说不出来的违和感。

图标的扩展也很奇怪。两个界面之间字体跑偏很容易发现。图标跑偏更难说清,但感受上更刺耳。大脑处理象形符号比处理文字更快,这意味着它察觉图标不一致比察觉文案不一致更快。

把图标当成一个连贯系统来交付的产品,即使其余工作粗糙,也显得精致。把图标当成自由混战来交付的产品,即使其余工作很锋利,也显得廉价。

---

网格就是系统

每个一致的图标库都从网格开始。网格是每个图标都要吸附其上的隐形脚手架。没有它,图标的尺寸、粗细和视觉平衡都会漂移,代码评审时也没办法强制保持一致。

基础网格

选一个基础网格尺寸,然后就住在里面。2026 年有效的两个默认值:

• 24 像素网格,用于产品 UI 图标。大多数现代界面的标准尺寸。
• 20 像素网格,用于高密度数据界面、仪表盘和后台工具。

网格不只是画布尺寸。它还包括画布内图标真正落位的活动区域。24 像素网格有一个 20 像素的活动区域,四周各留 2 像素内边距。内边距让图标有呼吸空间,也避免它紧贴相邻元素而显得局促。

网格内的关键线

活动区域内部有控制形状的关键线。20 像素的活动区域有四种关键线形状:

每条关键线都能在同一尺寸下产生视觉平衡的图标。一个 18 像素的圆看起来比 18 像素的正方形小,因为人眼会把圆形读得更小。关键线就是用来补偿这个感知上的怪癖。

把描边粗细做成 token

选一个描边粗细,然后坚持到底。大多数产品图标系统在 24 像素网格上使用 1.5 像素或 2 像素的描边。根据品牌调性来选。

1.5 像素的描边读起来轻盈、技术感、现代。2 像素的描边读起来自信、友好、易于亲近。3 像素的描边读起来粗犷、童趣或印刷风。选一个。把它记录为 token。任何使用不同粗细的图标投稿,一律拒绝。

设计 token词汇表讲了描边粗细如何嵌入更大的 token 架构。

---

视觉校正才是分水岭

数学上的对齐不等于视觉上的对齐。完美吸附网格的图标常常看起来不对,因为人眼不测量像素,它测量的是感知到的重量与平衡。

为什么需要视觉校正

20x20 像素的圆和 20x20 像素的正方形,读起来并不一样大。正方形完全填满它的边界框,视觉质量更大。圆的四角有空白,眼睛会把它记录为一个更小的物体。

解决办法是把圆画得比边界框稍大一些,有时大 1 到 2 像素。数学说错,眼睛说对。永远相信眼睛。

常见的视觉修正

五种修正覆盖了大部分图标工作:

• **圆形看起来比正方形大。**把圆形关键线放大 1 到 2 像素。
• **三角形看起来比正方形小。**把三角形关键线放大 2 到 3 像素。
• **斜线看起来比水平线细。**给斜线增加 0.25 到 0.5 像素的粗细。
• **不对称图标的中心会漂移。**播放按钮、箭头和 chevron 要靠眼睛做视觉居中,绝不要按边界框。
• **尖角看起来更小。**把内角稍微圆化,以匹配外角的感知重量。

这些修正不是个人观点。把任何图标的数学完美版和视觉校正版在小尺寸下并排测试。视觉校正版永远获胜。永远。

---

会不断累积的风格决策

网格和粗细确定之后,其他每一个风格决策都要一次做好,然后处处沿用。其中任何一项不一致,都会让人觉得这个库被太多只手碰过。

圆角半径

选一个外圆角半径和一个内圆角半径。两者成对工作。

1 像素外半径加 0.5 像素内半径,读起来利落、现代。2 像素外半径加 1 像素内半径,读起来友好、圆润。完全没有圆角的方正风格,读起来有建筑感、严肃。

错误的做法是在同一个库里混用半径。哪怕只有一个图标的转角比其余的更锐利,看起来也像是从别的图标集借来的。

端点与连接

描边有端点。端点可以是方形、圆形或突出形。描边之间的连接可以是斜接(尖)、圆形或斜切(切角)。每种选一个,并在整个系统里统一使用。

圆形端点加圆形连接,会得到友好、亲切的图标集。方形端点加斜接连接,会得到精确、技术感的图标集。同一个库里混用端点,会得到一套看起来没做完的图标。

填充 vs 线框

大多数现代图标系统为每个图标提供两种变体:用于非激活状态的线框版,和用于激活状态的填充版。线框版使用描边。填充版是同样的形状,内部填满。

两种变体必须视觉平衡。同样尺寸下,填充版往往读起来更重、更抢眼。解决办法是把填充版的占位缩小 1 到 2 像素,让它在同一比例下的视觉重量与线框版匹配。

焦点状态词汇表讲了从线框到填充的切换如何融入更广泛的交互状态设计。

---

命名是系统的一半

一个有 200 个精心绘制的图标、却没人找得到的库,就是没人用的库。命名是可发现性这一层,糟糕的命名扼杀采用率的速度比糟糕的绘制更快。

能扩展的命名模式

用对象优先命名,而不是隐喻优先。放大镜的图标叫 search 或 magnifier,绝不叫 find 或 look。对象是稳定的。隐喻则随语境而变。

多词图标使用 kebab-case:arrow-left、chevron-down、cloud-upload。大小写风格一致,工程师才能 grep 图标库、在 IDE 里自动补全,并且不出拼写错误。

只在需要时使用方向后缀。光有 arrow 不够。arrow-left、arrow-right、arrow-up、arrow-down 是最小集合。chevron、caret 以及其他任何带方向的象形符号同理。

变体命名

当一个图标有多个变体(线框、填充、双色)时,把变体作为后缀追加:

• search(默认线框)
• search-filled
• search-duotone

这种模式让工程师可以直接把 search-filled 放进按钮,而不用翻另一个文件夹。可预测的命名比完美的组织更快。

同义词映射

最大的命名失败,是设计师因为搜错了词而找不到图标。在图标库旁边建一份同义词映射。cart 也匹配 bag、shopping。home 也匹配 house、dashboard。delete 也匹配 trash、remove、bin。

大多数现代图标搜索工具(Iconify、Lucide、Phosphor)都在搜索界面里内置了同义词映射。内部图标库也要建一份,否则就接受设计师会因为找不到已有图标而不断添加重复图标。

---

治理让系统活下去

上面这些技术决策,任何称职的设计师都能复现。治理决策才是让系统活下去、还是在第二年死掉的分水岭。

唯一可信来源

选一个放图标的地方。可以是 Figma 库、存放 SVG 的代码仓库,或者像 Iconify 这样的托管服务。选一个。图标库就住在那里。每位设计师从那里取。每位工程师也从那里取。

有两个可信来源的系统,等于没有可信来源。Figma 库和代码库到第三周就会漂移,从那以后每个界面交付的图标都与系统不匹配。

贡献流程

把新增图标的流程写成文档。流程必须包括:

1. **先搜索。**确认这个图标没有以别的名字存在。
2. **说明新增理由。**用一句话写明这个图标代表什么、会用在哪里。
3. **按规范绘制。**匹配现有库的网格、描边粗细、圆角半径、端点和连接。
4. **视觉评审。**由另一位设计师在 16、20 和 24 像素尺寸下检查图标的视觉平衡。
5. **命名并交付。**名称遵循命名模式。在同一个 PR 里同时交付到 Figma 和代码。

没有贡献流程的系统,就是会被绕过的系统。设计师第一次急需图标时,就会从免费图标包里下载并直接上线,连问都不问。从那以后,图标库就有了一个分叉。

弃用流程

图标会被弃用。一次改版淘汰了旧风格,一个功能被砍掉,一次品牌焕新改变了视觉语言。要写明图标如何离开图标库,而不只是如何进入。

在库中为被弃用的图标加上显眼的标签。保留 90 天,让现有界面有时间迁移。然后移除。一个从不移除图标的库会变成博物馆,而博物馆是会被忽视的。

---

图标如何交付到代码

设计与代码之间的交接,是大多数图标系统崩掉的地方。Figma 库一尘不染,代码库却是一片不一致 SVG 的坟场,工程师对两边都不再信任。

SVG 就是格式

用 SVG 交付图标。不用 PNG,也不用图标字体。SVG 是矢量,可无损缩放到任意尺寸,支持 currentColor 继承以便轻松换主题,而且体积小到可以内联进组件。

每个 SVG 都有与网格匹配的 viewBox(24x24 或 20x20),描边和填充使用 currentColor,并且不含多余的 transform 或样式。干净的 SVG 不到 1 KB。大多数图标库交付的图标有 3 到 5 KB,因为它们是按默认设置导出的,里面嵌入了没人需要的元数据、transform 和内联样式。

优化没得商量

每个 SVG 在进入代码仓库之前都要跑一遍 SVGO。SVGO 会剥离元数据、简化路径、移除多余属性,平均能把文件体积削减 60% 到 80%。

对于一个有 200 个图标的库,未优化和已优化的差别通常是每次页面加载多出 400 KB。这会拉低 Lighthouse 分数,造成核心网页指标的倒退,让移动端体验无缘无故变慢。

组件封装

把每个 SVG 封装进带类型的组件(React、Vue、Svelte)。组件接收尺寸、颜色和无障碍相关的 props。工程师永远不直接导入原始 SVG。他们导入的是 <Icon name="search" size={20} />,剩下的交给系统处理。

这种模式意味着图标库可以更换底层导出格式(SVG、雪碧图、图标字体),而不用改动使用方代码。组件是 API,SVG 是实现。

设计交付词汇表讲了更广泛的交付纪律。图标是少数设计师与工程师真正共同拥有的领域之一。

---

常见的图标系统失败

每次图标审计都会撞上同样的失败。如果系统带着其中任何一项上线,这个库离一次彻底重写就只差一次改版。

**一个库里有三种描边粗细。**几乎总是意味着这个库是从多个免费图标包拼出来的。解决办法是强制把整套图标按一种粗细重画。

**填充与线框变体比例不一致。**填充版读起来比线框版大,因为没人补偿感知重量。解决办法是把填充版缩小 1 到 2 像素,直到两者读起来一样大。

**圆角半径不一致。**一半图标是圆角,一半是直角。几乎总是因为两位不同的设计师在没有书面规则的情况下各自投稿。解决办法是定义一个半径,然后重构。

**按隐喻命名。**图标被命名为 find、look、discover,而不是它所描绘的对象。设计师找不到它们。解决办法是改名为对象优先的约定。

**没有弃用流程。**图标库有 350 个图标,其中 80 个没人用或已被替换。臃肿拖慢搜索,也让新设计师困惑。解决办法是每季度审计一次,并建立 90 天的弃用周期。

---

2026 年条件下的图标系统

三个变化改变了图标系统的构建方式。系统必须能撑过它们。

**可变图标字体已成现实。**新格式让一个图标文件承载多种粗细、填充和光学尺寸,并能平滑插值。技术优势巨大,设计风险在于团队因为能做就在每个界面上交付每一种变体。选出要交付的变体。其余的砍掉。

**AI 工具几秒钟就能生成图标。**Midjourney、DALL-E 和 ChatGPT 用一条提示词就能产出一个过得去的图标。风险是设计师不再画图标而改为提示图标,而这会破坏系统一致性,因为每条提示词产出的风格都略有不同。AI 用来出初稿。每个产出都要重构,以匹配系统。

**Lucide、Phosphor 和 Heroicons 设定了基线。**这些开源库交付 1500 多个图标,网格、粗细和命名都保持一致。对大多数产品来说,从其中之一出发再定制,比从零开始更快更好。只有开源库没覆盖的产品专属概念,才画定制图标。

WCAG 词汇表讲了约束图标对比度和标注的无障碍基线。交互元素中的图标需要可访问的名称,而不只是视觉标签。

---

FAQ

图标系统应该使用多大的网格?

通用产品 UI 用 24 像素网格,高密度数据界面用 20 像素网格。网格四周各留 2 像素内边距,剩下 20 或 16 像素的活动区域供图标真正落位。选一个,整个图标库都住在里面。

图标描边应该多粗?

在 24 像素网格上是 1.5 到 2 像素。1.5 像素读起来轻盈、技术感,2 像素读起来自信、友好。选一种粗细,把它记录为 token,并拒绝任何使用不同粗细的投稿。

图标设计中的视觉校正是什么?

即使数学上说已经对齐,也要调整图标让它们看起来平衡的做法。圆形看起来比正方形大,三角形看起来更小,斜线看起来比水平线细。视觉校正就是补偿这些感知上的怪癖。永远相信眼睛,而不是边界框。

图标应该用填充还是线框?

大多数现代系统两种都提供。线框用于非激活状态,填充用于激活状态。两种变体必须视觉平衡,这通常意味着填充版比线框版小 1 到 2 像素,让感知重量匹配。

设计系统中的图标该如何命名?

对象优先、kebab-case,需要时加方向后缀。用 search,不用 find。用 arrow-left,不用 back。使用同义词映射,让设计师可以用替代词搜索。追加变体后缀(filled、duotone),让工程师一次导入就能拿到正确的变体。

什么时候该做定制图标,什么时候用开源库?

以开源库(Lucide、Phosphor、Heroicons)为基础。只为这些库没覆盖的产品专属概念定制绘制。2026 年从零开始做一套 300 个图标几乎总是白费力气。定制开源基础,记录新增内容,然后交付。

系统会自己回本

一个一致的图标库,是让产品显得精致最便宜的办法。一个不断漂移的图标库,是让产品显得廉价最快的办法。构建系统的成本是一到两周有纪律的工作。不构建的成本,是产品交付的每个界面都要永久缴纳一笔视觉税,永远如此。

选一个网格。选一个粗细。选一个圆角半径。选一种命名模式。写好贡献与弃用流程。优化 SVG。把它们封装进带类型的组件。然后在代码评审中把这一切强制执行。

每个界面上的图标列,是产品品质密度最高的信号之一。一次做对,它就能带着其余的设计走。

如果你想要一个把图标系统作为更广泛设计系统交付一部分来构建的团队,雇用 Brainy。网格、治理和代码在一个项目里完成,绝不是最后才硬塞进去。

相关阅读

• 设计系统指南
• 视觉层级设计
• 从 Figma 到开发的设计交付
• 网页无障碍检查清单