团队把图标方案从iconfont换成iconify了，说说我们的思考

作者：YeeWang

原文：https://juejin.cn/post/7189164727485300793

‍说到 icon，很多前端开发只能想到 iconfont，或者组件库中提供的那些图标，当然这对于绝大多数开发场景是够用的。

但要知道，iconfont 的方案其实是在 2016 年公开，到现在也已经有 6 年之久，它确实在这一段时期的设计领域中，独树一帜的解决了图标的问题，这么多年也有了丰富的积累沉淀。但是前端的发展是日新月异的，图标领域其实这些年也出现了很多新起之秀。

满足现在的方案，往往是因为眼界还不够。（没见过更好的）‍

哪里满足不了我？

字体

iconfont 以字体的方式加载和展现图标，启发于早期的 Bootstrap 等主流前端 UI 框架，iconfont 加入自由成组，自定义生产字体的方式，在那个时代确实非常超前了。但随着前端工程的不断碎片化，每个组件都有可能单独引入、按需打包，对于整包引入使用的这种方式，会与现有的架构设计有许多冲突：

• 无法按需引入：字体包的生产是在 iconfont 远端，需要手动创建与生产，在灵活的项目中，无法做到精准的 Tree Shaking，一切依赖于手动操作的流程都会趋于混乱。

• 网络开销大：对于字体加载来说，总会有 font 请求发出，一些项目为了字体的格式兼容性甚至选择使用多种字体格式，来处理浏览器的兼容问题。假如组件中的 icon 都是独立的字体，那么一个完整的页面，或许会有非常多的字体请求发出。

• 图标稳定性差：iconfont 平台会提供一份图标地址，域名是 at.alicdn.com ，许多业务在使用过程中甚至都没有考虑其 CDN 表现。这如果被使用在国际化场景下的话，是比较危险的操作。并且随着图标数量的不断增加，字体大小也会不断增加，随时可能会出现用户看不到图标的情况。

• 字体冲突：iconfont 是通过使用 font-family 设置不同的全局字体名 和 字符串 来区分图标的，但如果一个页面中存在 2 个相同名字的字体库，就会出现无法解决的冲突。比如：2 个组件都用了默认名称的字体名。

• 代码提示：前端开发体验在 Vite、TS 的出现后，出现了翻天覆地的变化，以前靠记忆、约定的许多前端规范，现在使用 ts 后都可以变得有据可查，信手拈来。但如果你还是在使用这种 字体 + 样式名 的方式，就只能去文档查询对应的图标具体的 class 是什么，这忍不了。

  声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/木道寻08/article/detail/795230