必须内联：需交互、变色、读屏支持；用<img>：仅静态装饰、背景或loading动画。内联SVG可被CSS/JS操作、支持:hover和currentColor；<img>引入则为黑盒，无法穿透样式或操作内部结构。
选 <img> 还是内联 SVG，关键不在“哪个更高级”，而在于你接下来要做什么。能交互、要变色、需读屏支持？必须内联；只是放个静态图标、背景装饰、loading 动画？<img> 更干净。
内联 SVG：适合需要控制和语义的场景
把 SVG 代码直接写进 HTML（比如 <svg><path d="..."></svg>），它就成为 DOM 的一部分，所有路径、文字、分组都能被 CSS 和 JS 直接选中。
- 支持
:hover、:focus、@keyframes动画，可对单个<path>填充色、描边、透明度做精细控制 - 能用
currentColor自动继承父级文字颜色，也兼容 CSS 变量，方便主题切换 -
<text>元素和aria-label、<title>可被屏幕阅读器逐字读出，图标含关键信息（如“已通过”+对勾）时不可替代 - 注意保留
viewBox属性，删掉会导致缩放异常；xmlns在 HTML5 中可省略，但保留更稳妥 - 避免在 SVG 内写
style="fill:red"这类内联样式——会覆盖外部 CSS，增加维护负担
<img> 引入 SVG：适合轻量、静态、复用型资源
用 <img src="icon.svg"> 加载 SVG，浏览器把它当作一张普通图片处理，内部结构完全不可见、不可操作。
- CSS 无法穿透：写
img.icon path { fill: blue; }完全无效；想模拟变色只能靠filter: drop-shadow()或整体透明度，精度差 - 本地双击打开 HTML 文件时容易空白——因为没 HTTP 服务，服务器没返回
image/svg+xmlMIME 类型 - 每个
<img>都是一次独立请求，10 个图标 = 10 次 HTTP 请求（HTTP/1.1 下明显拖慢） - 优势明显：体积小（SVG 文件可被 gzip 压缩）、支持浏览器缓存、HTML 干净、首屏解析快
- alt 属性有效，适合纯装饰性图标或仅需基础可访问性的场景
别踩坑：常见误判与折中方案
不是所有“看起来要交互”的情况都必须内联。有些需求其实有更轻量的解法。
立即学习“前端免费学习笔记（深入）”；
- 只要求悬停换色、且图标是单色的，可用 CSS
filter: invert(1) brightness(1.2)+transition快速实现，无需内联 - 图标复用率高、数量多（如导航栏、工具栏），推荐用
<symbol>+<use>构建 SVG sprite，再以内联方式一次性注入，兼顾复用与控制力 - 需要 fallback 到 PNG（如旧 IE），又要求一定交互性，
<object>是折中选择，但注意 Safari 对其load事件支持不稳定 - 地图、数据图表等复杂 SVG，优先走
<img>或懒加载，避免阻塞首屏 HTML 解析；内联大 SVG 会显著拉长DOMContentLoaded时间
怎么选，一句话总结
看 SVG 承担的角色：如果它是界面中的“活元素”——要响应、要读出来、要随主题变色、要动画路径，就内联；如果它只是“一张图”——起装饰、占位、指示状态，就用 <img>。不复杂，但容易忽略真实需求。
