之前帮团队搭过一个内部组件库，图标这块吃了不少亏，当时用的是阿里 iconfont。后来带新人的时候，发现很多同学对阿里矢量图标的认知还停留在“下载一个 iconfont.js 然后掉个 class”这种程度，遇到线上图标不显示、小程序里字体失效这类问题往往一脸懵。所以把这几年的实际经验整理一下，从项目管理到代码接入、从 Web 端到小程序端、从常规流程到避坑心得，一篇讲清楚。
1. 方案选型思考：为什么阿里矢量图标（iconfont）是团队项目的种子选型
先说一个很现实的问题：一个前端项目，图标方案用图片、CSS 绘制、还是 Icon 组件库？2024 年的技术环境下，很多纠结其实没有太大必要。
1.1 三种主流图标方案横向对比
表格先放这，后面每一行都会展开：
| 方案 | 渲染方式 | 加载体积 | 多色能力 | 修改样式 | 维护成本 |
|---|---|---|---|---|---|
| 图片雪碧图 | <img>/background | 较大，多份文件 | 有限 | 难，需要重做图 | 高 |
| 阿里 iconfont | 字体 / SVG Symbol | 小，按字符引用 | Symbol 支持 | 容易，CSS 控制 | 中低 |
| 组件化图标库 | 生成 React/Vue 组件 | 与项目打包 | 支持 | 容易，但依赖库更新 | 低（需锁定版本） |
图标库方面，我们早期确实用过一个开源组件库，图标很全，但问题在于样式被封装死了。PM 某个版本提了个需求，说按钮图标要加一个呼吸闪烁的动效，开源库怎么实现？只能改源码或者等官方支持。用 iconfont 的话，就一个 CSSanimation的事儿，完全不纠结。
1.2 为什么中央仓库模式更适合协作开发
再往前说一点，单个项目中用局部图标是很舒服的，但一旦涉及 5 人以上的前端团队，或者有一个公共样式包在多个项目里被依赖时，阿里 iconfont 的“在线链接 + 统一维护”模式就体现出巨大优势了。我把图标统一放在一个 iconfont 项目里，前端组所有同学都有权限上传与更新。
改动一次，所有项目刷新一下就能看到新图标。相比本地黑盒式的图片文件夹，这种“中央仓库”模式不会出现“图标在 A 项目是旧版、B 项目是新版”的分叉。
另外一个关键点是一般 iconfont 的图标本身通过 SVG 路径数组存储，在矢量放大场景下完全不糊。
所以结论很明确：Web 端 + 小程序端 + 跨端复用，阿里 iconfont 是种子选型，这个定位在项目初始阶段就值得固定下来。
2. 从 0 到 1：阿里矢量图标（iconfont）项目创建与图标管理
方案定了之后，就到了实操环节。很多同学习惯直接去 iconfont 官网搜索然后下载单个文件，这对临时 Demo 没问题，但团队协作和正式项目最好不要这么干。花 5 分钟建立一个“图标项目”才是正解。
2.1 建立图标项目的基础动作
在阿里 iconfont 首页登录后，进入“资源管理 -> 我的项目”，点击“新建项目”，会看到几个配置项：
- 项目名称：建议用团队公共前缀，比如
company-market-web-iconfont，一眼能看出归属和场景。 - 项目描述：写清楚这个图标库适用什么业务，方便不同团队复用。
- 字体格式：默认全选（TTF、WOFF、SVG、EOT）。这四项必须全选，因为不同浏览器内核会解析不同的字体格式。只留 TTF（TrueType）会在老旧浏览器（如 IE11）下引发字体加载失败。
项目建好后会产生一个FontClass前缀，默认是icon-开头，看得到iconfont-xxxx这样一串字符。这个前缀你可以按需修改成g-icon-、custom-图标-这种团队都有感的标识，后端同学也能看懂是什么。
2.2 添加图标的完整流程与批量技巧
项目创建好之后，进入图标收集环节。我这里把路径和步骤写全：
- 在 iconfont 官网搜索需要的图标。
- 鼠标悬停在图标上会看到“购物车”样式的小图标，点击可以加入“购物车”。
- 页面右上角进入“购物车”，点击“添加至项目”，选择你刚建好的项目。
还有一点容易被忽略：iconfont 支持批量添加。如果你有一整套 UI 设计稿，里面 30~40 个图标都要用，不用一个个手工加购物车。直接在搜索结果页勾选多个图标，统一“添加入库”，效率立刻翻倍。我们之前处理过一版后台管理系统重构，30 个图标大概花了不到 10 分钟就全部收集完毕。
入库之后还是需要对图标做一些“保洁”工作：
- 检查命名：我见过有些图标自动带 UUID 后缀，比如
icon-295B4A1。这种名字放进代码里简直是灾难。建议在“编辑图标”里把它改成可读性强的语义名，如icon-order-success。 - 去掉不需要的多余图标：项目里有 200 个图标，实际业务里可能只用了 30 个。多余的图标会让最终的字体文件变大，加载变慢。建议以迭代的方式，只把真正要用的图标放在项目里。
这里还有一个小技巧：将自己的常用图标“收藏”，下一次新建项目时可以直接从收藏夹拉取，不需要重新搜。
2.3 图标编辑与颜色处理规则
iconfont 网站内的图标编辑功能支持对 SVG 路径进行查看和简单操作。但对于我们这些开发者来说，真正需要关注的是“单色“ 与 ”多色” 图标的属性差异：
- 单色图标下载下来是纯黑色的 SVG 路径。引用时可以通过 CSS
color和font-size极方便地调整颜色和大小。 - 多色图标（比如银行卡、微信、支付宝等品牌类图标）使用的是多 SVG 路径。这种在 Font Class/Unicode 模式下会不遵循
color属性，整体会显示为默认多色。
注意：如果团队里设计师交付的是品牌相关的多色图标，而你要统一它们的颜色，建议在 iconfont 编辑器里 “换色模式” 改成“单色”，或者直接重新上传单色路径。否则后面调试会费掉很多时间。
3. 三种核心引用模式：Unicode / Font Class / Symbol
iconfont 项目页面里最关键的其实是“使用方式”这块，因为这里决定了你怎么在代码里去消费这些图标。我这边把三种方式都过一遍，并告诉你它们各自的“为什么”。
3.1 Unicode 方式：最原始但兼容性最好
Unicode 方式的核心原理是字体映射。下载到本地的字体文件里，每个图标对应一个 Unicode 码位（类似）。使用方法是在 CSS 中定义一个@font-face，指定font-family: "iconfont"，然后在 HTML 中插入一个<span>标签，它的内容就是那个 Unicode 字符，最后给这个<span>设置font-family: "iconfont"。
具体代码：
<!DOCTYPE html> <html> <head> <style> @font-face { font-family: "iconfont"; src: url('iconfont.eot'); /* IE9 */ src: url('iconfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */ url('iconfont.woff2') format('woff2'), url('iconfont.woff') format('woff'), url('iconfont.ttf') format('truetype'), url('iconfont.svg#iconfont') format('svg'); } .iconfont { font-family: "iconfont" !important; font-size: 16px; font-style: normal; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; } </style> </head> <body> <span class="iconfont"></span> </body> </html>优点：所有浏览器都支持，不依赖额外的 JS。缺点：字符是“神秘数字”，别人一看<span></span>根本不知道是哪个图标，维护起来要想半天。所以这个模式适合个人工具小项目，团队中大项目你别用它做主方案。
如果你的项目有国际化需求，注意 Unicode 私用区字符（E000-F8FF 之间）不会被本地化工具错误替换，这也是它兼容性好的一种体现。
3.2 Font Class 方式：真正的日常首选
Font Class 方式解决了 Unicode 方式“不直观”的问题。它本质上是这样运作的：
- 项目中的每个图标在
iconfont.css中都有一个专属的::before伪元素类。 - 使用时，HTML 中直接写
<span class="iconfont icon-close"></span>。
它比 Unicode 方式多了一层“类名语义”的抽象，代码的阅读和借用体验好太多了。以icon-close为例，其实际源码是这样：
.icon-close:before { content: "\e601"; }你在 Web 端要使用 Font Class 时，只需要把iconfont.css和相关的字体文件放到自己项目中，并在main.js或样式入口文件中引入。
import './assets/iconfont/iconfont.css';或直接：
<link rel="stylesheet" href="./assets/iconfont/iconfont.css">成功引入后，代码里这样写：
<span class="iconfont icon-search"></span>想吃这个图标变大变小加颜色，直接 CSS 操作：
.icon-search { font-size: 24px; color: #ff6600; }这一套在 Web 端真的是“从能用到好用”的顺手省心方案，也不需要处理任何 JS 逻辑，适合绝大多数中后台管理系统、官网、活动页。
3.3 Symbol 方式：支持多色与高级动效的最佳选择
Symbol 方式是阿里 iconfont 三巨头里最现代也是能力最强的一种。它引用的是 SVG 的<symbol>定义，把图标内容定义成<symbol id="icon-xxx">这样的结构，然后在需要展示的地方用<use>标签引出来。
引用方法：
- 下载项目中的
iconfont.js（它是一个封装好的 JS 脚本，里面包含了所有图标的 SVG<symbol>）。 - 页面加载时执行它，或者直接在
<body>中引入：
<script src="./assets/iconfont.js"></script>- 在需要的位置：
<svg class="icon" aria-hidden="true"> <use xlink:href="#icon-delete"></use> </svg>关于xlink:href，这里可以提一嘴：老的浏览器（IE 系列）只支持xlink:href，现代浏览器用href就行。为了兼容性，建议用xlink:href并同时保留href，有些构建工具做了 polyfill，那就无所谓了。
Symbol 方式的优势在于 SVG 本身是矢量图形，支持多色与CSS动效。之前的“呼吸闪烁按钮图标动效”需求，就是在这种方式下轻松解决：
.icon { width: 1em; height: 1em; vertical-align: -0.15em; fill: currentColor; overflow: hidden; animation: breath 2s infinite; } @keyframes breath { 0% { opacity: 1; } 50% { opacity: 0.3; } 100% { opacity: 1; } }这个fill: currentColor是有讲究的。它让 SVG 的颜色从父级 CSS 的color继承，这样你仍能以一种统一的方式去控制它的展示色，不会因多色 SVG 路径而失控。
4. Web 端接入实战与加载优化
接下来我们进入真正的大型项目落地阶段。线上项目我接手过的不少，Web 端接 iconfont 有三个层次：能用、够用、好用。我们要努力做到“好用”，而且要让团队后续维护不变形。
4.1 字体文件本地化还是使用在线 CDN
很多人图省事，直接在 iconfont 官网上复制在线链接放进项目。强烈不推荐这种直接把远程 CDN 链接写死在代码里的做法，原因有两个：
- 外部不可控：iconfont 官网的 CDN 稳定性虽然整体不错，但我们团队曾遇到一次前沿网络波动期，壳子里的图标全部变方块，因为这个白屏巡检和告警折腾了一整夜。
- 修改不够实时：每次在 iconfont 项目里新增图标，都重新生成在线链接，同时又要去代码侧更新 URL，很容易出现文件变了但 HTML 里的链接没更新的缝隙。
我推荐的操作方案：在 iconfont 官网点击“下载至本地”，会拿到一份压缩包，里面包含iconfont.css、iconfont.eot、iconfont.svg、iconfont.ttf、iconfont.woff、iconfont.woff2、demo_index.html等文件。
将这一整套文件直接放进项目的src/assets/iconfont/下，然后通过打包工具作为静态资源处理。
还有进阶玩法：用构建工具进行图标自动化集成。比如 Webpack 的copy-webpack-plugin，或者用vite-plugin-svg-icons构建本地 SVG sprite，前端配合一个脚本，自动把上传到 iconfont 的图标下载并覆盖本地目录。这个属于高效的自动化玩法，适合基建条件较好的团队。
4.2 CSS 引入与 Font-Face 路径坑位
本地化之后，iconfont.css中的@font-face路径默认是指向文件同目录的./iconfont.woff2这类相对路径。如果你的 CSS 文件不是跟字体文件在同一级，或者你的构建工具会对 URL 做处理，请务必确认打包后的实际路径。
举个例子，项目结构是这样的：
src/ assets/ iconfont/ iconfont.css iconfont.woff2 styles/ index.scss如果你在styles/index.scss里编写@import "../assets/iconfont/iconfont.css";，那么其中的相对路径会被解析为../assets/iconfont/iconfont.woff2，这大概率是对的。但如果有些工具会把字体文件重命名加哈希，你需要配合publicPath设成绝对路径，避免 CSS 中字体指纹加载 404。
我当时在 Vite 项目中遇到过一回：所有图标在“生产环境构建”时能显示，但是本地 dev server 刷新时偶尔出现方块。原因竟然是 Vite 在 dev 模式不会自动给字体文件新增 hash，而本地又把/assets/这个相对路径解析错了。
后来统一把@font-face全部改成：
@font-face { font-family: "iconfont" !important; src: url('/assets/iconfont/iconfont.woff2') format('woff2'), url('/assets/iconfont/iconfont.woff') format('woff'); }配合构建时统一把字体文件拷贝到 public/assets/iconfont/ 下，问题才彻底消失。
排查字体路径最快的办法：打开浏览器 Network 面板，刷新页面看字体请求的状态码。能看到 woff2 请求且状态码为 200，基本就不会出现方块问题。
4.3 按需加载与性能优化策略
很多团队在使用 iconfont 时，最担心的是把 30 个图标变成 1 个 3MB 的巨大字体文件。但其实这些字体文件（woff2）本身对汉字这种全量字符集才大，对几十个图标字体撑死了也就几十 KB，通常情况下并不用过度焦虑。
但如果你想极致优化，可以参考“按需生成”思路：
- 在 iconfont 官网生成新项目的过程中，只把自己要用的图标添加进去，不随手全选。
- 如果团队里图标很多，可以拆多个字体包，如“基础图标包”“业务图标包”“品牌图标包”，而不是一个大而全的 fat 包。
- 对首屏场景，优先只加载 Font Class 的基础图标包；对于二屏或交互后出现的图标，延迟加载额外字体包。
实测数据：一个基础包（约 50 个图标）压缩后的 woff2 大概 20~30KB，增量包加载耗时完全可以接受。用font-display: swap（CSS 的font-display属性）可以避免字体加载阻塞文字渲染，掉 FOUT（无样式字体闪烁）风险。
@font-face { font-family: "iconfont"; src: url('iconfont.woff2') format('woff2'); font-display: swap; }有人说“font-display: block 才不会闪图标”，其实这是反的。块级阻塞会让元素在字体加载期间隐藏，表现为“不可见的占位”，刷新时反而有一种图标的“弹跳感”。一般建议用swap，让图标和文字都能快速展示，即使字体加载慢，也只是先显示文本占位。
5. 小程序端与 uni-app 的 iconfont 正确接入姿势
前端团队跨端协作可以说是家常便饭。阿里 iconfont 在小程序端的接入与 Web 端有很大差别，最核心的一点是小程序 CSS 不能直接加载远程字体。
5.1 微信小程序原生接入
微信小程序的wxss支持@font-face，但只能使用 base64 内联字体（也就是“Data URI”格式），不支持直接给一个 HTTPS 字体链接。官方原生框架对于远程字体有着严格的域名限制，即使开发工具能加载，真机上也可能失效。
最稳妥的办法是“转 base64”：
- 在 iconfont 官网下载本地包。
- 把
iconfont.ttf通过 base64 工具转成data:font/truetype;charset=utf-8;base64,AAEAAAA...这样字符串。 - 在小程序的
app.wxss或全局样式中声明：
@font-face { font-family: 'iconfont'; src: url('data:font/truetype;charset=utf-8;base64,AAEAAAA...') format('truetype'); } .iconfont { font-family: 'iconfont' !important; font-size: 16px; font-style: normal; }然后在 wxml 中使用：
<text class="iconfont"></text>这个小技巧对我们这种多人协作项目极其有效：字体以 base64 打包在全局样式里，一套代码全局可用，不用在每个子包都放字体文件。
必须强调：base64 内联会让
app.wxss体积增加几十到一两百KB。如果你对包体积有执念，可以采用“分平台按需加载”：只在需要的子包页面放一个 partial 样式，局部引入字体。
5.2 uni-app / Taro 跨端接入
如果是 uni-app 或 Taro 这种跨端项目，建议换个思路。你完全没必要在小程序端用 base64 方式硬扛，很多时候可以用SVG 或者图片代替为一个通用组件。
以 uni-app 为例，可以直接注册一个全局图标组件：
<template> <view class="icon-box" @click="handleClick"> <text v-if="isFontClass" class="iconfont" :class="fontClass"></text> <image v-else :src="svgUrl"></image> </view> </template>如果你的项目是 H5 与小程序两端同跑，H5 端使用 Font Class，小程序端则把图标下载为 PNG/SVG 位图，这样维护成本低且不整花活。
同样，Taro 3 中可以直接用taro-iconfont-cli这类工具包，它会自动把阿里 iconfont 项目里的图标生成对应的Icon组件。实测接入后小程序端显示 SVG 确认非常顺滑。
6. 版本更新与团队协作规范
这里要谈论一个多数教程都不会提到的点：当团队里多人共用同一个 iconfont 项目时，如何保证发布的变更不影响正在进行的开发。
6.1 命名规范与图标回收规则
我建议团队内部约法三章：
- 新图标命名必须贴合业务语义，不允许出现
icon-未命名2、icon-155222。 - 废弃的图标及时清理，但清理前必须搜索一下全局代码是否有引用，避免线上 404 图标显示成方块。
- 采用“版本化”思路：如果你不想破坏线上稳定，新建一个
xxx-v2的 iconfont 项目，把新增图标放进去，通过加载两个字体文件共用一套 Font Class 前缀都不冲突。
这第 3 点非常实用。比如你有一个project-manage-web-iconfont，在做大版本迭代时，新图标计划全部以project-manage-web-iconfont-new为项目名生成。你可以在新的项目里把已有共享图标也复制一份。等到新版本全部验证通过后，再割接新项目链接。
6.2 在线链接的“一次性”更新与缓存治理
如果你确实使用在线链接，图标更新后，浏览器/小程序可能仍然走缓存，出现“明明改了什么图标，刷新还是旧图标”的尴尬情况。
处理方式：
- 在 URL 后加版本号或时间戳，比如
iconfont.css?v=20241206。 - 或者通过构建工具自动给链接追加
hash。只要打包产物的html中注入的链接是带 hash 的，用户端不会命中旧缓存。
有一个踩过的坑必须提：因为有些浏览器只缓存 EOT/woff，如果你经常只改 iconfont.css 的文字，但字体文件本身的文件名不变，浏览器可能直接吃老字体。此时必须在 iconfont 官网重新生成项目链接后再下载新字体，否则改了等于没改。
7. 高频 Bug 排查目录：图标不显示的根因与处置
这部分是全文价值密度最高的地方。我把这几年见到过的 iconfont 故障都整理成速查表，免得大家出问题时手忙脚乱。
7.1 图标变成方块 / 空白
| 可能性 | 判定方式 | 解决方案 |
|---|---|---|
| 字体文件未加载/路径 404 | Network 面板查看.woff2/.ttf请求 | 修正@font-face路径或改为相对路径 |
| 字体格式与浏览器不匹配 | 高版本 Chrome 只支持 Woff2 却只有 ttf | 下载完整格式包或补充 Woff2 |
CSS 中font-family被覆盖 | 检查类名优先级和全局样式 | 给.iconfont增加!important |
| 在线链接被墙/网络问题 | 浏览器直接访问链接是否通 | 离线化字体包至本地 |
7.2 Font Class 类名不生效
类名不生效通常有几个原因：
- 你把
iconfont.css引入位置放在了组件样式之后，总之优先级被覆盖。 - 你拼写少了前缀
iconfont或icon-。 - 你的 iconfont 项目里Symbol 模式生成的和 Font Class 模式生成的代码引用方式搞混了。Font Class 与 Symbol 的引入方式不同，不要混用。
补充一个非常常见的错误：用 Font Class 时，HTML 中class="iconfont icon-xxx"两个 class 都不能少。.iconfont提供字体族基础样式，.icon-xxx提供具体的字符映射。丢了前缀，图标直接显示成“一个方框+数字”。
7.3 Symbol 引用时<use>内部空白
很多人引用 Symbol 时，图标不显示，检查<svg><use xlink:href="#icon-xxx"></use></svg>后，发现#icon-xxx确实存在。问题几乎都出在<svg>的宽高/填充色上：
svg.icon { width: 1em; height: 1em; fill: currentColor; }如果不设置宽高，部分浏览器里 SVG 的默认宽高是 0。如果不设置fill，单色图标也可能因为默认fill是黑色而显得过于死板。如果是多色图标且没有添加fill，它就维持原 SVG 内部颜色展示。
7.4 小程序中字体完全不显示
首先排除 wxml 是否写的是<text class="iconfont"></text>而不是<text class="iconfont icon-xxx"></text>。小程序不支持::before伪元素引入字符的 hack，其兼容性支持只对最传统的 Unicode 模式可靠。但如果你引入了伪造的 Font Class 在小程序端硬写 class，可能不显示。
所以在小程序端最好只使用 base64 内联的@font-face+<text>&#xxxx;</text>模式。如果你在小程序中搞定了字体加载，这个方案最稳。
7.5 “图标变丑”或线条毛糙
图标边缘锯齿或模糊一般有两个原因：
- 使用了非矢量缩放：有些方案使用位图
background-image，小尺寸下会模糊。 - font-size 过小还好解决，但真的大原因通常是渲染引擎在非整数缩放时的亚像素平滑缺失。可以设置 CSS 的
transform: scale()来强制对齐或使用偶数像素字号，例如移动端 24px、Web 端 16px/32px 这类常见整数像素。
这一点上 Symbol（SVG）有明显优势：矢量尺寸任意缩放不模糊。
8. 基于真实项目的接入记录与收益复盘
最后说说我们团队的一个中后台系统项目。
当时项目里已经堆积了大约 300 多个本地图片资源，图标散落在各个模块，有几个还重复命名。新版本重构时，我们决定把所有按钮、菜单、状态标识图标全部迁移到阿里 iconfont。
项目计划用了 2 天时间：
- Day 1：梳理页面所有图标，整理成清单（图标名、用途、引用位置）。
- Day 2：在 iconfont 官网批量搜 + 批量入库，命名成统一
icon-module-name格式，下载全套本地文件，替换页面代码。
最终效果：
- 图标资源体积从原来的 8.2MB 减少到了 90KB（字体文件 + CSS）。
- 页面加载图标请求数量从 20+ 减少到 1 个字体请求。
- 后续 PM 改图标颜色/大小，前端只需改一行 CSS，不需要再用 Photoshop 改图后重新上传。
- 新员工接手项目时，看到
icon-order-pay就知道这个图标是“订单支付”的，理解成本直线下降。
当然我也得承认，这个项目的成功不全是 iconfont 带来的，还有我们做了图标规划与命名规范。但如果一开始就引入阿里 iconfont 并遵循规范，重构的工作量还能再压缩一半。
9. 常见问题快速速查卡
以下这个速查卡是给团队内自用的，很推荐大家直接复制到团队 Wiki：
| 症状 | 核心根因 | 快速处置 |
|---|---|---|
| 图标整体变方块 | 字体文件加载失败 | 检查@font-face路径和 CDN 网络 |
| 部分图标不显示 | 字体文件是重新生成的但浏览器缓存 | 给链接加版本号或强刷缓存 |
class="iconfont icon-xxx"无效 | 引入 CSS 冲突或类名写错 | 按顺序检查font-family、前缀、类名 |
| 多色图标全部同一色 | 使用了 Font Class/Unicode，但图标是多色 | 改为 Symbol 方式，或换成单色图标 |
| 小程序图标不显示 | 未使用 base64 内联字体 | 转 base64 并在 wxss 中声明 |
| Symbol 图标颜色变不了 | SVG 的fill被静态设置 | 使用fill="currentColor" |
| 图标太大/太小 | font-size或svg宽高未设置 | 用 CSS 控制 |
| 图标在构建后 404 | publicPath 或 assets 路径变了 | 检查构建产物与 public 资源路径 |
10. 阿里 iconfont 的未来扩展：图标自动化与设计资产联动
这个内容想作为收尾，提一个很多人没往深处想的方向：iconfont 和设计稿的联动。
我们团队现在有这样一个实践：设计师在即时设计或用 Figma 里产出图标，如果是 SVG 格式，会统一上传到 iconfont 项目。前端在做需求时，不需要等设计切图，直接去 iconfont 找复用就行，前端与设计之间甚至可以通过 iconfont 的“群组”功能共享一个团队账号。
往后一点，还可以思考“图标同步工具化”的问题。比如写一个小脚本，通过 iconfont 的公开接口读取项目字体文件，定时向公司自己的 CDN 推送。图标变更后，只要 CDN 刷新，几十个项目的图标就全部同步了。这种自动化听起来很舒服，但前提是团队内部先把“图标命名—上传—引用”这条链路规范化，不然自动化只会加速混乱。
我自己在折腾过这些之后，最大的体会是：图标这种小东西，平时不起眼，但一旦乱起来，它能把整个团队的开发效率拖垮一大截。所以如果你现在正在一个新项目初期，花半天时间把 iconfont 项目建好，把规范定好，后面能省下无数个跟“图标为什么是方块”搏斗的深夜。
