1. 为什么还在手动写 SVG——搞清楚它和 PNG 的真正差异
SVG 这个东西，说新不新，说旧不旧，但到现在还有不少同学对它的认知停留在“能缩放不会糊”的层面。我刚接触 SVG 那会儿也一样，觉得它就是位图的替代品，后来真花时间把 SVG 当工程来用之后，才发现这个理解偏差很大。
先厘清一个概念：SVG 的全称是 Scalable Vector Graphics，中文叫可缩放矢量图形。它本质是一段 XML 文本，用标签描述图形，而不是像 PNG、JPG 那样去记录每个像素点的颜色值。这意味着你在浏览器里看到的一个圆形，在 SVG 里就是一行<circle>标签加上 cx、cy、r 三个属性。这一点直接决定了它的几个关键特性：无限缩放不失真、文件体积可以做到极小、可以用 CSS 和 JavaScript 控制内部元素、甚至可以完全由代码生成。
我见过很多人把 SVG 当成“放大不模糊的图片”来用，这个说法不能说错，但它只讲出了最表层的东西。SVG 真正的价值在于它的“可编程性”。你去设计网站时，如果只需要一个静态 logo，导一张 SVG 放在那里，其实和放一张 PNG 差别不大。可一旦你希望这个 logo 在小屏幕上换个颜色、在加载完成后画一笔动画、或者配合 JS 做点交互效果，SVG 就是唯一能让你“改内部结构”的格式。
举个生活化的类比：位图有点像拍立得照片，拍完了就是那个样子，你想把照片里的人换个衣服颜色，只能重新拍或者后期重画；SVG 则像一份乐高图纸，每个零件都标注得清清楚楚，你想改哪个零件就改哪个零件，甚至还可以让零件动起来。理解了这层差异，你才会明白为什么现在越来越多的图标系统、数据可视化和动效设计都往 SVG 上靠。
这篇文章适合谁看？如果你是前端开发、UI 设计师、或者只是做个人项目时需要处理图形的爱好者，下文从手写一个 SVG 开始，到嵌入网页、响应式适配、动画交互，最后再到优化和调试，覆盖的是一个完整的使用链路。我会默认你会一点点 HTML 和 CSS，JS 部分不会涉及太复杂的语法，尽量让你看完就能直接上手。
2. 从零手写一个图标：坐标、路径语法与基础图形实操
2.1 先忘掉编辑器，从一个圆和矩形开始
很多人第一次接触 SVG，习惯性打开设计软件导出一份代码，然后直接复制粘贴。我建议你至少手写一次基础图形，因为只有亲手写过坐标和属性，才能在后期调试时一眼看出问题。先在文件里放一段最基础的 SVG：
<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg"> <circle cx="100" cy="100" r="50" fill="#ff6b6b" /> <rect x="20" y="20" width="160" height="160" fill="none" stroke="#333" stroke-width="2" /> </svg>这段代码做了两件事：画了一个红色实心圆，圆心在画布正中间，半径 50；又画了一个描边矩形，从坐标 (20, 20) 开始，宽高都是 160。
注意几个基础概念。width和height是画布的实际尺寸，cx和cy是圆心的坐标，坐标原点默认在左上角，x 轴向右，y 轴向下。这一点和数学里的坐标系不太一样，如果你之前用 Canvas 比较多，应该对这套坐标体系不陌生。fill是填充色，stroke是描边色，stroke-width是描边宽度。
我这里用的xmlns是 XML 命名空间声明。在浏览器里直接粘连到 HTML 中使用时，可以省略它；但如果把 SVG 存成独立文件，这个声明建议保留，否则部分解析器会报错。这个细节很容易被忽略，等你把代码贴到某些 XML 严格模式的场景里就明白有多重要了。
2.2 路径语法：那些看着吓人的 M、L、C 到底是什么
看完基础图形，你已经能应付简单场合了，但真正绕不开的是<path>标签。图标系统、地图轮廓、复杂曲线，基本全靠 path 表达。第一次看到 path 里的d属性，一堆字母和数字连在一起，看起来很像乱码，其实拆开看非常简单。
<path d="M10 80 C 40 10, 65 10, 95 80 S 150 150, 180 80" fill="none" stroke="#333" stroke-width="3" />字母是命令，数字是参数。M是 Move To，移动画笔到指定点，不画线；L是 Line To，画一条直线到指定点；C是三次贝塞尔曲线，后面跟三组坐标，分别是控制点一、控制点二和终点；S是平滑贝塞尔曲线，自动镜像上一段曲线的控制点；Z则是闭合路径，从当前位置画直线回到起点。
为了把坐标感建立起来，我们结合一个实际场景：画一个简单的对勾图标。我用的是经典的两段线：
<svg viewBox="0 0 24 24" width="24" height="24"> <path d="M4 12.5 L9 17.5 L20 6.5" fill="none" stroke="#2ecc71" stroke-width="3" stroke-linecap="round" stroke-linejoin="round" /> </svg>这里的 M 开头的移动命令其实可以省略，直接从第一个点开始画线。stroke-linecap="round"让线段端点变成圆头，stroke-linejoin="round"让拐角变成圆角。很多人画出的线条图标很生硬，就是忘了这两个属性。加上之后观感会立刻柔和下来，几乎成了手绘感图标的标配。
如果你计划深度使用 SVG，建议把d属性里的常用命令打印成小抄贴在显示器旁边：M、L、H、V、C、S、Q、T、A、Z。其中 H 是水平线，V 是垂直线，Q 是二次贝塞尔，T 是二次平滑贝塞尔，A 是圆弧。不用急着全部掌握，先熟练 M、L、C 就够用了。
2.3 组、变换和样式继承
画单个形状不够过瘾的时候，把多个形状组合复用是常规操作。<g>是分组标签，它本身不画东西，但会把子元素打包成一个整体。分组的好处显而易见：可以统一设置样式，做整体位移和旋转，还能被 CSS 类选择器整体选中。
<svg viewBox="0 0 100 100" width="200" height="200"> <g fill="#e74c3c" stroke="#333" stroke-width="2"> <circle cx="30" cy="50" r="15" /> <circle cx="70" cy="50" r="15" /> </g> </svg>这样两个圆都会继承 fill 和 stroke 属性，省去了重复书写的麻烦。但你也要知道继承的限制：fill和stroke这类可视属性可以继承，x、y、width这些几何属性不会继承。
变换是另一个常用工具。transform属性支持 translate、scale、rotate、skewX、skewY 和 matrix 六种操作。我最初犯过一个低级错误：直接把 transform 写成 CSS 形式transform="translateX(10px)"，结果浏览器不认。SVG 属性语法用的是transform="translate(10, 0)"，坐标单位去掉 px，用空格或逗号分隔。真正到了内联 SVG 里，你又可以完全抛开属性写法，改用 CSS 样式来写 transform，这就是两种写法并存容易让人混淆的原因。
3. 把 SVG 塞进网页的五种姿势及其取舍
3.1 到底有哪几种引入方式
SVG 写好了，问题来了：网页里究竟怎么放它？我见过不少人在这一步开始困惑，因为方式实在太多了。这里的核心选择不是“哪个最好”，而是“哪个最适合当前场景”。
第一种，img标签引入：
<img src="logo.svg" alt="logo" width="120" height="40" />这是最朴素的方式，适合纯粹展示一个静态图形。SEO 友好、写法简单，大多数现代浏览器都支持，但它有硬伤：无法用外部 CSS 控制 SVG 内部的样式，也无法监听内部元素的事件。想改颜色？只能改 SVG 源文件，或者搞出多个颜色版本，非常麻烦。
第二种，CSS background 引入：
.icon { background-image: url('icon.svg'); width: 24px; height: 24px; }适合纯粹装饰性图形，特别是雪碧图场景。它和 img 的限制差不多，而且因为没有 alt 属性，对屏幕阅读器也不够友好。纯装饰图标这么用没毛病，担当内容图标时建议换别的方式。
第三种，内联 SVG：
<div class="icon"> <svg viewBox="0 0 24 24"> <path d="..." /> </svg> </div>这是我最推荐用于交互场景的方式。SVG 标签直接在 DOM 里，CSS 可以精准选择到内部的<path>和<circle>，JS 也可以轻松 addEventListener。你可以把一个图标在 hover 时从实心变成描边，点击时改变颜色，甚至给不同部件绑定不同事件。代价是 HTML 里会多出一堆代码，但现代构建工具一般都有inline-loader或者组件机制帮你处理这件事。
第四种，object标签：
<object type="image/svg+xml" data="logo.svg" width="200" height="100"></object>这在老项目中偶有出场，最大的优势是外部 CSS 无法渗入，内部样式也不会泄漏到页面，适合当你需要严格隔离的场景。缺点也明显：交互能力远不如内联，而且历史上不同浏览器的行为差异很大，我一般不太推荐新项目去用。
第五种，用 data URI 嵌入。把 SVG 内容做 URL 编码后塞进 CSS 或 img 的 src 里，减少一次网络请求。适合小图标，但可读性极差，维护不方便。
3.2 内联 SVG 为什么必然是交互场景的首选
我把话说得更直接一点：你只要想在页面上控制 SVG 内部元素的任何状态，就不要用 img。内联 SVG 的优势完全取决于它的 DOM 参与度。
举个例子，实现一个用户点击后小圆点从红色变成蓝色。如果用 img 方式，你根本碰不到内部那个<circle>，只能换图片。用内联 SVG，代码可以简化为：
<svg width="100" height="100" id="dot"> <circle cx="50" cy="50" r="30" class="dot-circle" /> </svg> <style> .dot-circle { fill: #e74c3c; transition: fill 0.3s; } #dot:hover .dot-circle { fill: #3498db; } </style>这个 hover 变色效果在 img 方式下是写不出来的。CSS 选择器能够穿透进去，是因为内联 SVG 成了当前文档 DOM 的一部分。还有一个隐藏福利：内联 SVG 的中文文本可以直接被搜索引擎抓取，这在 logo 或图表含文字内容时是个不小的优势。
我个人的经验准则是：如果这个 SVG 是内容型或交互型，用内联；如果它只是装饰，用什么都可以，尽量选 img 或 CSS 背景。不要去追求“全站统一一种插入方式”，那是教条的做法。
3.3 用图片方式引入时，CSS 样式为什么老是失效
这个坑我踩得特别深。接手一个老项目时，用 img 引入了一个 icon，然后在外部管理样式表里写了.icon-inner { fill: red; }，一刷新发现完全没变化。当时的反应是“CSS 写错了吗”，查了半天才发现，SVG 作为图片资源加载时，浏览器会把它放到独立的文档上下文里，外部文档的 CSS 根本不会作用到它内部。这是隔离机制使然，不是你的选择器优先级问题。
如果确实要用 img 方式，又想改内部颜色，最合理的办法是准备多个 SVG 源文件，或者通过服务端动态返回不同颜色的 SVG。我见过有些图标系统为了规避这个问题，直接把每个颜色都导出一份文件，文件数量瞬间膨胀，维护成本非常高。这时候你就能理解为什么前端圈子都在推崇内联 SVG 或字体图标方案了。
4. 响应式与适配：不辜负矢量的核心优势
4.1 viewBox 和 width/height/百分比的关系
SVG 的 viewBox 是很多新手最懵的属性。它并不是视觉上画布的大小，而是定义了一个“虚拟坐标系”。举个例子：
<svg viewBox="0 0 100 100" width="50" height="50"> <circle cx="50" cy="50" r="50" /> </svg>viewBox 的前两个数字是虚拟坐标系的原点，后两个数字是虚拟坐标系里的宽高。也就是说，这个 SVG 不管最终渲染成 50 像素还是 500 像素，内部坐标始终按 0 到 100 来计算。圆心的 cx=50 永远是中心点。
这个机制让 SVG 天生自适应。只要设置了 viewBox，width 和 height 缩小放大会等比影响整个虚拟坐标空间。一旦没有 viewBox，只有 width 和 height，SVG 会直接把内部元素按像素来布局，缩放时要么裁切要么超出画布，非常别扭。
写响应式页面时，我常常这么干：固定 viewBox，不写 width 和 height，只设 CSS：
.svg-cover { width: 100%; height: auto; }只要你设置了height: auto，浏览器就会按 viewBox 的宽高比自动算出高度，图片不会变形。这一点和普通 img 的做法一致，但很多人因为给 SVG 加了个固定的 height，导致它在窄屏上特别突兀。
4.2 preserveAspectRatio：控制缩放时的裁切与留白
SVG 的强大还体现在一个不那么显眼的属性上：preserveAspectRatio。它解决的问题是，当外部容器的宽高比和 viewBox 的宽高比不一致时，SVG 该怎么办。
默认值是xMidYMid meet。meet 的意思是完整地展示整个图形，类比于 CSS 里的object-fit: contain，会留白；而slice则类比object-fit: cover，会裁切超出的部分。后面那串 xMidYMid 决定图形在容器里的对齐位置。
<svg viewBox="0 0 100 100" preserveAspectRatio="xMidYMid slice" width="200" height="100"> <!-- 内容会填满 200x100，但边缘会被裁掉一些 --> </svg>我做全屏背景装饰图形时，经常把它设为 slice 加 xMinYMin，让图形贴着容器左上角对齐，同时填满整个区域。这个属性在普通响应式布局里用得少，但一旦涉及数据可视化图表或背景纹理，就非常关键。你不想让一个宽屏图表在小手机屏幕上被压缩得扁扁的，就得学会用它来控制表现。
4.3 切图和图标系统的搭配建议
围绕响应式，还有一个实操层面的老问题：SVG 该不该为每个尺寸单独切一份？答案是不需要。一份 SVG 源文件放到不同尺寸的容器里都能完美缩放。你唯一要注意的是最小和最大缩放范围。比如一个很复杂的呼吸图标，缩放到 16px 时，内部细节可能糊成一团，线条间距也容易处分不清。这种情况单纯依赖矢量缩放解决不了，你得检查源文件里的最小描边宽度。我通常的建议是，图标最少在 24px 下有良好的视觉表现，再小就该考虑为 16px 特化一份简化版。
图标系统方面，如果项目里有一堆 SVG 图标，别把它们打成一大堆内联代码。比较流行的做法是用 SVG 雪碧图：把所有 symbol 集合到一个文件里，使用时用<use>引用：
<svg><use href="#icon-home"></use></svg>这种方式既保留了内联 SVG 的灵活性，又避免了每个页面都重复粘贴几十行路径代码。构建工具如 Vite、Webpack 都有对应插件来自动生成雪碧图，配置一次后就非常省心。
5. 动画与交互：让静态图形动起来的实战手法
5.1 用 CSS 动画覆盖多数常见的动效需求
SVG 动画最快上手的路径不是 SVG 自己的动画语法，而是你已经会的 CSS。属性fill、stroke、opacity在浏览器里对 SVG 元素而言都是可动画属性。配合 CSS transition，hover 变色何止小菜一碟，简直可以让整个图标跟着情绪走。
.like-icon path { fill: #ccc; transition: fill 0.2s ease, transform 0.2s ease; } .like-icon:hover path { fill: #ff4757; transform: scale(1.1); }transform在 CSS 里作用于 SVG 元素时，默认的变换原点跟普通 HTML 元素不一样。普通元素默认以自身的中心为原点，SVG 元素则默认以 SVG 画布的左上角为原点。这导致你直接写transform: scale(1.2)时，图形会往右上角跑，而不是在原地变大。解决办法也很简单，设置transform-origin: center，或者明确指定坐标：
.like-icon path { transform-origin: 50% 50%; }这个问题我见太多人踩过，包括我自己第一次给图标加缩放动画时也愣了整整半天。
5.2 SMIL 动画与现代使用场景
CSS 动画覆盖不了场景时，比如沿路径运动、动画随着 SVG 内部元素顺序来播，可以考虑 SMIL 动画。SMIL 里的<animate>、<animateTransform>和<animateMotion>直接把动画声明写在 SVG 内部，浏览器原生支持，不需要引入 JS 库。
<svg viewBox="0 0 100 100" width="100" height="100"> <circle cx="10" cy="50" r="5" fill="#e74c3c"> <animate attributeName="cx" from="10" to="90" dur="2s" repeatCount="indefinite" /> </circle> </svg>这段代码会让一个圆点在 x 方向上来回移动。SMIL 的优势是简单直接，一条动画声明就能搞定沿路径移动这类 CSS 特别难做的事情。缺点也很明显：SMIL 的动画逻辑埋藏在 HTML 里，跟 CSS 的统一管理比确实有点乱，调试也不太方便。我现在的团队策略是：重复的、状态相关的动画用 CSS 和 JS；如果真要做到一个图形沿着路径走动，才会把 SMIL 请出来。
5.3 用 JS 控制 SVG 元素的交互
交互的方向很多，JS 才是自由控制态的兜底。比较常见的场景是生成数据可视化图表。此时通常用 D3.js 这类库来操作 SVG 的 DOM。你甚至可以不用库，原生 JS 也能实时改 SVG 属性：
<svg width="200" height="200" id="target"> <rect x="40" y="40" width="120" height="120" class="box" /> </svg> <script> const box = document.querySelector('.box'); box.addEventListener('click', () => { const isExpanded = box.getAttribute('width') === '200'; box.setAttribute('width', isExpanded ? 120 : 200); box.setAttribute('x', isExpanded ? 0 : 40); }); </script>SVG DOM 和 HTML DOM 在基础操作上没太大区别，你可以 getAttribute、setAttribute、appendChild，理论上怎么操作 HTML 就可以怎么操作 SVG。唯一需要注意的是 SVG 元素的坐标属性有时候会被字符串或者数字类型搞混，setAttribute 时格式要写对，否则图形位置直接就偏了。
还有一个小经验：事件委托同样适用于 SVG。如果图中有几百个图元，给每个图元绑定事件很容易造成多余开销。不如给父级<svg>绑定一个 click，然后在事件对象里判断target.closest('.data-point')，这样无论节点增加还是减少，都不用重新绑定事件。
6. 优化、兼容与调试：老手踩过的坑和解决办法
6.1 导出 SVG 之后文件为什么这么大
很多时候 SVG 并不是手写的，而是从设计工具里导出的。这时候文件里往往藏着一堆你看不懂的节点、层叠样式和内嵌数据。设计工具为了保证编辑友好，会把很多零碎的信息都写进 SVG 里。最终文件比 PNG 还大，一点都不奇怪。
这种场景需要用一个叫 SVGO 的工具来压缩。SVGO 会去除不必要的元信息、合并路径、换算精度，甚至嵌套简化。用 npx 一条命令就能处理：
npx svgo logo.svg --output=logo.min.svg我见过一个设计稿导出的 SVG 从 80KB 压到 6KB，视觉上完全没变化。对于图标类重资产项目，建议把 SVGO 集成到构建流程里，自动化压缩，不要让手艺人去手动处理每次导出结果。如果你用 Vite，它内置了 SVGR 和压缩插件生态，配置插件后导入的 SVG 都是处理过的。
6.2 viewBox 与 width/height 失配的经典问题
一个特别诡异的 bug：图标显示的时候要么被裁掉一半，要么四周多出大片空白。我排查过不少次，最后发现源头都是 viewBox 和 width/height 没有对应好。设计工具导出时，如果画板里包含了一些隐藏的元素，viewBox 的范围可能比可见图形大很多，视觉上就是图形变小、空白变多。
解决办法很简单：先用浏览器开发者工具查看 SVG 元素的边界框，然后根据实际内容微调 viewBox。手动写 SVG 时，我会先用一个临时样式把所有图形轮廓显示出来：
svg * { stroke: red; stroke-width: 1; }这样你能一眼看出图形实际占用的范围，再调整 viewBox 就心里有数了。
6.3 文本渲染和字体问题
SVG 里也可以放<text>标签。但它跟 HTML 文本不一样，如果你在里面用了一个网站访客电脑上没有的字体，字体就会回退成默认字体，排版立刻垮掉。最简单稳妥的方式是：把文本转换为路径再导出。设计软件里通常有一键转轮廓的功能，转成 path 之后不再依赖字体，视觉和布局都不会跑掉。
当然这样做也牺牲了文本的可访问性和可检索性。所以我的原则是：装饰性文字，转路径；数据图表上需要动态更新的文本，用<text>标签保留，并且通过 CSS 引入 Web 字体来兜底。
6.4 我的调试方法小结
调试 SVG 的时候，浏览器开发者工具其实是最好用的。Elements 面板可以直接查看 SVG 的 DOM 结构，Computed 面板能看到最终应用的样式，Network 面板能观察外部加载 SVG 的请求状态。大家对 HTML 的调试都很熟练，到了 SVG 却容易默认它管不了，实际上 Chrome 对 SVG 的调试支持已经非常完善。
我常备的快捷键是 Cmd+Shift+C，鼠标悬停在页面上就能定位 SVG 内部的每个元素，这时候看它的边界框、坐标、继承样式，问题定位非常快。还有一个实用技巧：右键点击 SVG 节点，选择 Copy > Copy outerHTML，能快速拿到当前修改后的 SVG 源码，方便回贴到设计稿或者代码仓库里。
如果你是把 SVG 当作图片用、但感觉渲染和预期不一样，建议在地址栏直接打开这个 SVG 文件，独立查看它。这能区分问题到底出在 SVG 文件本身，还是页面引入时的样式影响。排查思路清晰后，大部分问题十分钟内都能解决。
