iconfont字体图标本质上是阿里巴巴矢量图标库提供的Web字体解决方案，服务支持的字体格式包括ttf、woff、woff2、eot和svg五种，其中woff和woff2是当前浏览器兼容性和性能平衡最好的选择。
很多刚接触iconfont的朋友都会有个疑问：为什么我下载的图标在网页上显示不出来？其实大部分问题都出在字体格式的选择和部署方式上，下面我们从实际场景出发,把iconfont字体图标服务支持的字体这件事彻底讲透。
iconfont字体图标支持哪几种字体格式，各有什么优劣
iconfont的字体格式并非单一存在，而是根据不同的浏览器需求提供了多套方案，行业共识认为,一个完整的Web字体解决方案需要覆盖老版本IE到现代浏览器的全谱系。
五种常见字体格式的适用场景
- ttf格式：最通用的字体格式，Windows和macOS系统都能直接安装预览，放在Web上使用时，它主要服务的是Safari浏览器和老版本Android内置浏览器，ttf的缺点是文件体积偏大,且不支持字体压缩。
- woff格式：本质上是ttf的压缩版，压缩率通常在40%以上，它是Web字体的事实标准，Chrome、Firefox、Edge、Safari全系支持,是业界推荐的优先格式。
- woff2格式：woff的升级版，采用Brotli压缩算法，体积比woff再缩小约30%，现代浏览器全面支持,是当前性能最优解。
- eot格式：微软专为IE浏览器设计的格式，只用在IE6到IE11上，如果你的项目还需要兼容老旧的国产浏览器内核（比如某些政府网站）,eot格式依然要保留。
- svg格式：严格来说它不算字体文件，而是一种矢量图形格式，在iconfont中它扮演后备角色，仅用于早期iOS Safari（iOS 4.1及以下）,现在基本可以弃用。
实际部署时最少需要哪几种格式
如果你不是做极端兼容的老项目，没必要把五种格式全部引进去，业内专家指出，一个经过充分实践的方案是保留woff2和woff两种格式，最多再加ttf用于本地预览,这样做的原因很简单：
- woff2覆盖面已经超过95%的活跃浏览器
- woff可以作为旧版Android和部分桌面端浏览器的降级方案
- ttf仅供开发者自己打开看图标形状，不参与Web加载
表格对比会更直观：
| 格式 | 压缩率 | 支持主力 | 是否建议Web引用 | 备注 |
|---|---|---|---|---|
| woff2 | 最高 | Chrome/Firefox/Edge/Safari新版 | 强烈建议 | 首选格式 |
| woff | 较高 | 全系浏览器 | 建议 | 兼容降级 |
| ttf | 无 | Safari旧版/本地预览 | 可选 | 体积最大 |
| eot | 无 | IE8-IE11 | 看需求 | 老项目保留 |
| svg | 无 | iOS 4.1以下 | 不推荐 | 已淘汰 |
iconfont字体图标怎么用到网页上，三种加载方式的区别
选好了格式，接下来是使用方式，在iconfont官网，当你把图标加入购物车后，项目页会展示三种使用方式：Unicode方式、Font class方式、Symbol方式，这里不讨论代码层面的操作细节,重点说说它们和字体加载的关系。
Unicode和Font class方式的字体引用逻辑
这两种方式都属于传统Web字体技术，你会得到一个后缀为.css的链接或一段可复制的样式代码，里面注释掉了@font-face规则：
@font-face {
font-family: "iconfont";
src: url('iconfont.woff2?t=123456789') format('woff2'),
url('iconfont.woff?t=123456789') format('woff'),
url('iconfont.ttf?t=123456789') format('truetype');
}
看到这段代码你应该就明白了：iconfont服务支持的字体，在这两个方式下是通过@font-face引用的，浏览器会按顺序加载，优先用woff2，不支持就自动请求woff，再不行就ttf,这也是为什么官方建议你把woff2放在src第一行。
Symbol方式的特殊之处
Symbol方式不使用@font-face，它把每个图标封装成一个<symbol>标签，通过<use>引用来渲染，这种方式下字体文件完全不再参与加载，转而走SVG的路径渲染路线，好处是没有字体加载失败导致的空白方框问题，坏处是
如果你需要动态替换图标颜色，就得用CSS的fill属性，而不能直接用color。
iconfont字体不支持显示成方框的原因和解决办法
经常有朋友问：为什么我发布的iconfont在手机上显示成小方块？这是fonts加载失败的典型症状，据统计,大多数类似问题都集中在以下几个环节。
部署路径错误导致的字体文件404
iconfont官网上生成的代码，默认引用的是绝对网络路径，如果你把代码复制到本地项目里，http://at.alicdn.com开头的地址是能直接访问的，但如果你用了自定义域名或者本地化部署，就要把字体文件下载下来，然后在@font-face里改成相对路径。
排查步骤按顺序来：
- 打开浏览器开发者工具，切到Network面板，筛选Font类型
- 看看字体文件返回状态码是不是404或403
- 如果是，检查css文件中url的相对路径是否正确
- 确保
iconfont.woff2等文件与css文件在同一个目录层级
Content-Type响应头不对导致浏览器拒绝渲染
这个比较隐蔽，即使你的字体文件下载成功了，如果服务器返回的Content-Type不是font/woff2这类正确值，Chrome和Firefox会直接拒绝解析,解决办法是在服务器配置里加一条MIME类型映射：
Apache: AddType font/woff2 .woff2
Nginx: font/woff2 后缀自带处理，确认mime.types文件里包含该映射跨域访问限制
如果你的iconfont托管在CDN上，而主站域名和CDN域名不一致，就会遇到CORS错误，这时候需要在CDN配置里加上Access-Control-Allow-Origin响应头，iconfont官方CDN默认已经做了跨域处理，但自建CDN或OSS托管时经常漏掉这一步。
iconfont和Font Awesome对比，哪个更适合中国开发者
这是一个高频对比词，很多人在技术选型时都会纠结：用阿里巴巴的iconfont还是国外的Font Awesome？
从字体服务支持的角度看核心差异
- 字体格式数量：iconfont提供五格式方案，Font Awesome则侧重于woff2和woff组合，但两者在主流浏览器上都表现稳定
- 图标风格统一度：Font Awesome的图标风格高度统一，iconfont因为是用户上传共享，
风格差异较大
，需要你手动筛选 - 访问速度在国内的表现：iconfont的CDN节点在国内，Font Awesome的公共CDN在部分网络环境下加载较慢，行业共识认为，面向国内用户的项目优先选iconfont更稳妥
- Iconify等聚合库的兼容：如果你用框架组件库，两种字体图标都支持，这一点没有差异
什么时候你该放弃字体图标转而使用SVG
iconfont虽然好用，但字体图标在高清屏渲染和多色图标这两个场景下不如SVG灵活，如果你的设计要求图标包含两种以上颜色，字体图标做不到，这时候就应该去下载SVG文件而不是继续用字体格式，iconfont官网支持单独下载SVG,这一点是很多同类平台做不到的。
关于iconfont字体图标服务支持的常见疑问解答
iconfont的字体文件可以商用吗？
收费规则取决于具体图标的授权协议，iconfont平台本身提供免费和付费两种类型图标，免费图标的授权范围包括个人项目和非盈利商业项目，如果做收费主题或SaaS产品，最优做法是在项目设置里查看每个图标的授权说明,或者直接联系原作者获取单独授权。
为什么我把iconfont字体文件引入后网页首屏出现空白闪烁？
这叫做FOUT或FOIT现象，字体文件加载需要时间，浏览器在字体没就绪时会先用备用字体渲染，导致图标闪一下空白，解决办法是在@font-face里增加font-display: block让浏览器预留字体区域，或者在页面加载时先隐藏元素,待字体ready后再展示。
本地的iconfont支持直接改成CSS雪碧图那种方式使用吗？
不支持，字体图标只能走@font-face引用路线，如果你不想要字体请求，需要自己在iconfont项目里生成Symbol代码，它本质上是SVG雪碧图，这条路可以完成图标渲染,但不属于字体服务支持的范畴了。
说到底，iconfont字体图标服务支持的字体格式算得上全面且务实，对国内开发者而言，掌握woff2优先、woff兜底、ttf预览的组合拳，就足够应付绝大多数项目的图标需求，下次再遇到图标显示异常，按上面说的路径挨个排查,问题基本都能落地解决。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/586800.html
