图标库加载失败应先检查<link> href路径是否可访问：在Network面板中过滤CSS或字体文件，确认404/403错误；再验证@font-face中字体文件路径、MIME类型及font-display设置。
检查 <link> 标签的 href 路径是否可访问
图标库加载失败，第一反应不是改 CSS，而是确认浏览器能不能拿到那个文件。打开开发者工具（F12），切到 Network 面板，刷新页面，过滤 css 或直接搜图标库文件名（比如 fontawesome.css、iconfont.css）。如果状态码是 404 或 403，说明路径错了或服务器没配好。
常见问题包括：
-
href写成相对路径但当前页面 URL 层级变了（比如从/page/跳到/admin/user/，href="css/icon.css"就会请求/admin/user/css/icon.css） - 用了
//cdn.jsdelivr.net/...但本地开发时没开网络，或公司内网屏蔽了该 CDN - 路径里混用了大小写（Linux 服务器区分大小写，
IconFont.css≠iconfont.css） - 构建后路径被自动修改（如 Webpack 的
publicPath配错，导致生成的href指向/static/...但实际资源在/assets/...）
验证图标字体文件（.woff2/.ttf）是否真正加载成功
CSS 文件能加载，不代表图标能显示——图标通常是通过 @font-face 引入字体文件，而这些字体文件（.woff2、.ttf）常被漏掉或路径写错。Network 面板里继续过滤 font 或 woff，看有没有 404。
典型表现是：CSS 中定义了 .icon-home::before { content: "\e900"; }，但页面只显示空方块或问号。这时要查：
立即学习“前端免费学习笔记（深入）”；
- 字体文件 URL 是绝对路径还是相对路径？它相对于的是 CSS 文件位置，不是 HTML 位置
- CDN 上的字体文件是否存在？有些图标库（如早期 iconfont）需手动勾选「下载字体」并上传到自己服务器，不能只引 CSS
- Nginx/Apache 是否配置了字体 MIME 类型？缺失
woff2类型会导致浏览器拒绝加载（响应头Content-Type应为font/woff2）
检查 CSS 中 @font-face 的 src 声明是否匹配实际部署结构
很多图标库 CSS 里写的 src 是开发时的路径，比如：
@font-face {
font-family: 'iconfont';
src: url('./iconfont.eot');
src: url('./iconfont.eot?#iefix') format('embedded-opentype'),
url('./iconfont.woff2') format('woff2'),
url('./iconfont.woff') format('woff'),
url('./iconfont.ttf') format('truetype'),
url('./iconfont.svg#iconfont') format('svg');
}如果把整个图标目录挪到了 /assets/fonts/，但没改 CSS 里的 url(...)，就会全部 404。解决方式有两种：
- 用构建工具（如 PostCSS、Webpack）自动重写
url()路径（推荐） - 手动编辑 CSS，把所有
url('./xxx')改成url('/assets/fonts/xxx')（注意开头的/表示根路径） - 把字体文件放到和 CSS 同级目录下（最省事，但不推荐用于生产环境）
用 font-display: swap 避免图标闪动或阻塞渲染
即使路径全对，也可能遇到图标短暂不显示、文字替代符（如 [?]）一闪而过的问题。这是因为字体加载是异步的，默认行为是“等字体加载完再渲染”，尤其在弱网下明显。
在 @font-face 规则中加一行：
@font-face {
font-family: 'iconfont';
src: url('./iconfont.woff2') format('woff2');
font-display: swap; /* 关键 */
}这会让浏览器先用系统默认字体占位，字体加载完成后立刻替换——用户感知更平滑。注意：swap 在 Safari 10+ 和 Chrome 80+ 支持良好，老版本可降级为 fallback。
别忽略字体加载时机：如果图标元素在 JS 动态插入 DOM 后才触发字体加载（比如单页应用路由切换），可能需要手动调用 document.fonts.load() 或监听 fontloading 事件。
