我多年来一直说，一个非常好的图标 系统就是将图标与内联 <svg> 放在你需要的地方。这很简单，可以提供完全的设计控制，具有（通常）良好的性能，这意味着你不会因缓存和浏览器支持问题而头疼。
沿着这条思路…使用 <img> 也不是最糟糕的图标想法。它不提供那么细粒度的设计控制（尽管你可以仍然使用 filter 对它们进行滤镜处理），并且可以说没有那么快（因为图像需要单独从文档中获取），但它仍然具有与内联 SVG 图标许多相同的优势。
Shubham Jain 有一个名为 SVGBOX 的项目，它提供图标作为 <img>，并通过提供一个 URL 参数来更改颜色来消除一个设计控制限制。
想要一个 Instagram 图标，但要用红色？传入 red
如果你要使用一堆图标，提供的复制粘贴代码提供了一个“SVG 精灵”版本，其中 URL 类似于这样
<img src="//s.svgbox.net/social.svg?fill=805ad5#instagram">这将增加图标的下载权重（因为它正在下载来自此集合的所有图标），但可能更有效，因为它是单个下载，而不是多个下载。很难说这些天是否更有效，随着 HTTP/2 的出现。
有趣的是 URL 末尾的 #instagram 部分。只是一个哈希链接，对吧？不！更高级！在 SVG 领域，它可以是 片段标识符，这意味着它将只显示与正确 <view> 元素匹配的 SVG 部分。这种事情不常见。
该项目的作者在这里。Chris 说的没错，内联 SVG 提供最大的灵活性。但它也有一些缺点：你的代码会变得杂乱，很难将其用作背景和伪元素，而且就我个人而言，我觉得处理 imgs 更容易。
此外，HTTP/2 确实加快了资源的并发加载，但仍然有一些原因让你可能更喜欢串联。如果图标必须动态呈现（例如，假设下拉菜单在你将鼠标悬停在某些内容上后显示），那么使用单个 SVG 更好，因为新图标将立即呈现，而不是触发新的 HTTP 请求。
另一个优点是可以使用 LINK 标签来“预加载”图标集。最后，尽管 HTTP/2 大大加快了并发加载，但它也有其局限性。如果你要在页面上呈现 50 多个图标（例如，旗帜），则精灵将表现得更好。
或者让浏览器在客户端创建 SVG 图标；请参见 https://iconmeister.github.io