很多团队有很多图标，但没有图标系统。
这两者的差别很大：
- 有很多图标：设计稿里素材不少，开发也能找到 SVG 用
- 有图标系统：命名、语义、尺寸、状态和接入方式都清楚一致
如果没有系统，图标越多，反而越容易混乱。
图标系统的核心不是“画得好”，而是“用得准”
一个图标系统真正要解决的问题通常是：
- 同一个动作是否被不同图标反复表达
- 同一个图标在不同页面是否有不同语义
- 图标在设计稿、代码和文档里是否能一一对应
也就是说，图标系统的重点是语义一致性，而不是只追求视觉统一。
命名规则决定后续协作效率
图标最常见的问题之一，是文件名完全依赖个人习惯：
arrow-2new-icon-finaldownload-black
这种命名方式一旦进入项目，很快就会造成：
- 设计和开发找不到同一个图标
- 相似图标被重复创建
- 组件库里堆满历史遗留版本
更稳的方式是围绕语义命名：
arrow-rightdownloadnotification-filled
图标尺寸和视觉规则一定要标准化
图标系统如果没有统一规则，最常见的问题包括：
- 线宽不一致
- 角半径不一致
- 视觉重心不一致
- 小尺寸下清晰度失控
所以图标系统需要的不只是素材库，还需要规则：
- 基础网格
- 常用尺寸档位
- 填充 / 描边策略
- 小尺寸简化原则
真正的工程问题在导出与接入
很多团队以为图标系统完成于 Figma，其实不是。
真实项目里，图标要真正可用，还要解决：
- SVG 导出是否统一
- 是否需要压缩和清理属性
- 组件库如何暴露 icon API
- 主题切换时颜色策略怎么处理
如果这部分没打通，图标系统就只是设计资产，不是产品资产。
失败案例：设计稿里是同一套图标，代码里却出现三种风格并存
这是很多团队都会遇到的情况：
- 历史页面用的是旧图标库
- 新页面直接复制设计稿里的 SVG
- 组件库里又单独维护了一套 Icon 组件
结果就是一个产品里同时存在：
- 线性图标
- 面性图标
- 尺寸和对齐规则不同的图标
这会直接削弱界面的一致性，也增加后续清理成本。
图标系统要有生命周期治理
图标系统不是一次性产物，后续一定会发生：
- 图标废弃
- 图标合并
- 图标语义调整
- 新平台场景接入
所以你需要：
- 命名规范
- 文档目录
- 废弃规则
- 代码层引用追踪
只有这样，图标系统才不会随着时间膨胀成资产垃圾场。
一份可直接复用的检查清单
- 图标是否围绕语义命名，而不是围绕视觉细节命名
- 是否定义了统一的网格、线宽和尺寸规则
- 设计稿、导出文件和组件 API 是否能一一对应
- 历史图标和新图标是否有统一清理和替换策略
- 图标系统是否具备废弃和升级治理流程
总结
图标系统的价值，不在于“素材多”，而在于它能让设计、开发和产品在同一套语义下协作。只要命名、规则、导出链路和治理方式一起建立，图标才会从零散素材变成系统资产。
进一步阅读：
