用<svg>内联或独立文件更优：更轻量、免HTTP请求、CSS可控；但内联过多会增HTML体积；图标字体已不推荐，favicon需用.ico并避免CDN跨域问题。
HTML图标用 <img> 还是 <svg>？性能差得挺多
直接说结论：用 <svg> 内联或作为独立文件，比 <img src="icon.png"> 在多数场景下更轻、更可控。关键不是“能不能替代”，而是“替换了之后，哪些地方会变快/变慢/出错”。
常见错误现象：<img> 加载小图标时出现闪动、布局偏移（FOIT/FOUT）、缩放模糊；<svg> 未设宽高导致文档流塌陷或继承父级尺寸异常。
-
<svg>不发 HTTP 请求（内联时），省掉 DNS、TCP、TLS 开销；<img>即使是 1KB 的 PNG，也至少多一次网络往返 -
<svg>可用 CSS 控制颜色、大小、动画，fill和stroke能响应伪类；<img>换色只能靠滤镜或 JS 操作 canvas，成本高 - 但
<svg>内联太多会增大 HTML 体积，影响首字节时间（TTFB）和 gzip 效率；建议单页图标数 >10 个时，改用<svg>雪碧或<use>引用外部defs
SVG 图标在 flex 或 grid 布局里不居中？
这不是图标本身的问题，是 <svg> 默认 display: inline，基线对齐（baseline-aligned），和文字一样“坐”在文本行底线上，看起来像往下掉了一截。
- 最简解法：
<svg>加style="vertical-align: middle"或top/bottom，比改display: block更少破坏布局流 - 如果父容器是
flex，确保没漏掉align-items: center；<svg>本身不需要额外margin微调 - 别用
height: 1em硬撑——<svg>的viewBox才决定缩放逻辑，width/height只是容器尺寸，设成1em可能被字体大小意外拉伸
用 <link rel="icon"> 加载 favicon 性能要注意什么？
浏览器会在 HTML 解析早期就发起 favicon 请求，哪怕你把它放在 </head> 底部。这个请求失败或超时，会拖慢整个页面的“完成”状态（load 事件），尤其在弱网下明显。
立即学习“前端免费学习笔记（深入）”；
- 必须提供
.ico格式（至少包含 16×16 和 32×32 尺寸），Chrome/Firefox 对纯.png作 favicon 兼容性不稳，Safari 甚至可能忽略 - 路径写绝对 URL，避免相对路径触发多余域名解析；比如用
/favicon.ico，而不是./favicon.ico - 别把 favicon 放在 CDN 上却忘了配 CORS 头——虽然浏览器通常不报错，但某些安全策略下会静默失败
- 开发阶段可临时注释掉
<link rel="icon">测速对比，真实影响常被低估
图标字体（如 Font Awesome）现在还值得用吗？
基本不推荐新项目引入。它曾经解决多色、缩放、CSS 控制问题，但现在 <svg> + currentColor + mask 已覆盖全部需求，而图标字体的缺陷更突出。
- 字体加载阻塞渲染：即使图标只是装饰，
@font-face未就绪时，<i class="fa-home">位置留空或显示方块，且无法用font-display: optional安全降级 - 语义缺失：屏幕阅读器默认跳过
<i>，需手动加aria-hidden="true"和role="img"，维护成本高 - 字符集膨胀：引入整套字体（常 >100KB），只为用其中 3 个图标，gzip 后仍远大于等效 SVG 字符串
- 例外场景：极老系统（IE9 及以下）必须支持时，才考虑降级为图标字体；但这类项目本身已无优化必要
真正容易被忽略的是：图标资源是否参与关键渲染路径。一个 <svg> 内联进去，只要没触发 layout thrashing 或强制同步重排，它就是零成本的；但一个没配好 loading="eager" 的 <img> 图标，在 LCP 计算里可能直接成为瓶颈。
