SVG里的path是一条路径，是一条线，也是一个可以随意变形的图形。做矢量编辑工具、做可视化看板、做在线海报设计器，几乎都会碰到这样一个需求：用户想让某个图形跟着鼠标走，实时看到它在画布上的新位置。如果这个图形是rect或circle，处理起来很简单，直接改x、y或cx、cy就行。但碰上path这种由一长串坐标命令组成的东西，事情就没那么直接了。
这篇文章我会用最贴近实战的方式，把“SVG path 跟随鼠标拖动而实时移动”这件事拆开揉碎。先讲清楚为什么不能贸然去改d属性，再给出标准高效的实现方案，最后附上完整可跑的代码和我在真实项目中踩过的坑。无论你是刚接触SVG的前端新人，还是做图形编辑器需要进阶的开发者，这套思路都适用。
1. 先想清楚：拖动path到底在拖什么
1.1 直接改d属性为什么是大坑
拿到需求，很多人的第一反应是：鼠标mousemove的时候，把path的d属性里的所有坐标点都重新算一遍。听起来很直接，但实际操作起来会立刻暴露两个问题。
第一是性能。一个复杂的path，比如中国地图的省级边界，d属性里可能有几千上万个坐标点，有的甚至带有贝塞尔曲线命令。每次mousemove都要解析这一大串字符串，逐个点做偏移计算，再拼回字符串，然后触发浏览器重新解析和渲染。拖动一次下来，页面卡顿几乎是必然的。在低端机型上，这个卡顿会非常明显，用户只会觉得“这个东西真难用”。
第二是语义灾难。d属性是路径的原始定义，它承载了图形的几何形状信息。如果你为了拖动而修改d属性，等于把“路径的真实坐标”和“路径的位移状态”混在了一起。后续如果还要做缩放、旋转、撤销重做，或者导出SVG文件，你不得不去逆向解析这些坐标，才能搞清楚图形原本在哪个位置。这会让整个数据模型变得极其混乱。
正确的做法，是把“几何形状”和“位移变换”分离。几何形状永远保持不变，位移状态放在上一层的transform属性里。
1.2 用transform实现平移的本质原因
SVG里有一个g标签，也就是分组标签。把需要拖动的path放进一个g标签里，比如：
<g id="draggable-group"> <path d="M10 10 L100 10 L100 100 Z" fill="skyblue"></path> </g>拖动时，我们只更新这个g标签的transform属性：
group.setAttribute('transform', `translate(${offsetX}, ${offsetY})`);这个方案有两个非常明显的好处。
性能上，transform不会触发几何解析，浏览器只需要做一次矩阵运算，把整个组的内容偏移到新位置。对于复杂path，这个开销比修改d属性小了几个数量级。实测下来，即使是几千个坐标点的路径，在普通笔记本上拖动也能保持流畅。
语义上，几何数据始终干净。你随时可以读取原始path的d值，知道图形的最初形状和位置。位移只是一个附加状态，想Reset就清空transform，想保存就记录这个transform值。这对后续功能的扩展非常友好。
生活化地类比一下：改d属性就像是把一栋房子的每一块砖头都拆下来，重新搬到新位置再砌起来。而用transform，是直接给整栋房子装上了轮子，推过去就行了。显然，后者才是工程化的做法。
1.3 不同拖法对应不同策略
在实际项目中，“跟着鼠标拖动”这个需求，其实可以细分成几种情况，处理方式不完全一样。
第一种，拍平拖动。也就是说，不管鼠标在图形的哪个位置按下，图形都保持原有姿态，整体移动到鼠标位置。大多数拖拽需求都属于这一类，用户点住图形的头部，结果整个图形一起过来了。
第二种，自由位移。用户按下鼠标后，图形跟随鼠标的增量移动，也就是我们最常见的拖拽手感。按下时记录鼠标起点和图形当前位移，之后根据鼠标移动的增量更新位移。
第三种，拖拽路径上的某个锚点。这个就复杂了，比如三阶贝塞尔曲线的控制点拖动。它的本质不是改变整个图形的位置，而是改变某个点的坐标，进而改变path的形状。
这篇文章重点讲第一种和第二种，因为它们是日常需求里出现频率最高的，也是后续做锚点编辑、旋转缩放等功能的基础。理解了这一层的实现，后面改造出花来都不难。
2. 前置知识：SVG坐标转换与事件链路
2.1 页面坐标系和SVG坐标系不是一回事
做拖动，最重要的一个环节是坐标换算。这里有个很容易被忽略的基础知识：鼠标事件里拿到的clientX和clientY，是相对于浏览器视口的坐标。而SVG内部使用的是一个独立的坐标系，这个坐标系可能因为viewBox、缩放比例等因素和视口坐标系不一样。
直接拿clientX和clientY去计算SVG内的位置，是很多人犯的第一个错误。最典型的症状是：图形拖起来比鼠标慢半拍，或者鼠标在图形中心按下，结果图形“飞”到了别的位置。这些都是坐标系没对齐导致的偏差。
要解决这个问题，我们需要把鼠标的视口坐标，转换成SVG画布内的坐标。SVG提供了原生方法：
const svg = document.querySelector('#my-svg'); const pt = svg.createSVGPoint(); pt.x = event.clientX; pt.y = event.clientY; const svgPoint = pt.matrixTransform(svg.getScreenCTM().inverse());getScreenCTM()返回的是当前SVG元素到屏幕坐标的变换矩阵，对它取逆矩阵，就能把屏幕坐标反算回SVG坐标。这个过程，就相当于利用SVG内部的“坐标系答案”反推出某个屏幕点对应SVG里的哪个位置，非常关键。
如果你做了zoom缩放，比如画布放大2倍，依然可以使用这个方法，因为getScreenCTM()已经把缩放考虑进去了。这也是这套方案能在复杂项目里通用的原因。
2.2 三种可选的坐标转换API
除了getScreenCTM()，还有几个相关方法，我简单整理一下，方便你在不同场景里选型。
getBoundingClientRect()是DOM元素通用的方式，通过元素左上角和尺寸算出相对位置。它的算法是：
const rect = svg.getBoundingClientRect(); const x = event.clientX - rect.left; const y = event.clientY - rect.top;这种方式简单直观，在没有viewBox或viewBox恰好和元素尺寸等比例的情况下，结果基本正确。但一旦viewBox和实际尺寸比例不一致，或者CSS做了变形，这个算法的精度就会出问题。适合快速验证，不适合严谨的编辑器场景。
getScreenCTM()是SVG元素专属的方法，精度最高。它返回的矩阵包含了viewBox、CSS缩放等所有变换信息，用逆矩阵反算出的坐标完全准确。这是正规方案的首选。
还有一个SVGPoint，上面已经展示过，它是用来承载原始坐标并执行矩阵变换的容器对象。这个API在各大浏览器里都很稳定，没有兼容性焦虑。
2.3 事件链路的完整设计
拖动的本质，是“按下、移动、抬起”三个阶段的闭环。三个事件缺一不可，而且绑定位置也有讲究。
一个很常见的错误是把mousemove直接绑定在被拖动的元素上。实际运行起来你会发现，一旦鼠标移出这个元素，mousemove就不再触发，拖到一半图形就停住了，体验非常奇怪。
正确做法是：mousedown绑定在目标元素上，mousemove和mouseup绑定在document或更上层的容器上。这样无论鼠标移动到哪里，只要没有松开，移动事件都能持续触发。松开鼠标后再统一解绑，避免残留事件造成下一次拖动的干扰。
拖动的核心逻辑是：mousedown时记录鼠标的起始位置，以及当前图形的位移值。mousemove时计算鼠标的位移增量translateX和translateY，用初始位移加上增量，得到新的位移值，再写回transform。mouseup时只需要清理事件监听。
这套逻辑，用伪代码表示就是：
let isDragging = false; let startX = 0, startY = 0; let originX = 0, originY = 0; element.addEventListener('mousedown', (e) => { isDragging = true; startX = e.clientX; startY = e.clientY; originX = currentTranslateX; originY = currentTranslateY; document.addEventListener('mousemove', onMouseMove); document.addEventListener('mouseup', onMouseUp); }); function onMouseMove(e) { if (!isDragging) return; const dx = e.clientX - startX; const dy = e.clientY - startY; currentTranslateX = originX + dx; currentTranslateY = originY + dy; element.setAttribute('transform', `translate(${currentTranslateX}, ${currentTranslateY})`); } function onMouseUp() { isDragging = false; document.removeEventListener('mousemove', onMouseMove); document.removeEventListener('mouseup', onMouseUp); }这套逻辑是所有拖拽交互的地基，理解了它，后面加任何功能都是锦上添花。
3. 完整实现：让path拖起来并实时移动
3.1 首个可运行版本
下面给出一段可直接运行的HTML代码，先把最核心的路径拖动跑通。为了方便观察，我特意给path加了一个比较复杂、有曲线有直角的形状，以此展示它在拖动过程中的表现。
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>SVG Path 拖动演示</title> <style> body { font-family: sans-serif; background: #f5f5f5; } svg { background: #fff; border: 1px solid #ddd; cursor: grab; } svg:active { cursor: grabbing; } .tip { width: 800px; margin: 20px auto; color: #555; } </style> </head> <body> <div class="tip">按住下面的path拖动试试，图形会实时跟随鼠标移动。</div> <svg id="my-svg" width="800" height="500" viewBox="0 0 800 500"> <g id="draggable-group"> <path d="M 120 80 C 180 20, 260 60, 320 120 S 420 220, 420 280 L 420 340 Q 360 380, 300 360 L 200 420 Z" fill="rgba(66, 133, 244, 0.3)" stroke="#4285F4" stroke-width="3"> </path> <text x="250" y="220" font-size="18" fill="#333" text-anchor="middle">拖我</text> </g> </svg> <script> (function () { const svg = document.getElementById('my-svg'); const group = document.getElementById('draggable-group'); let isDragging = false; let startX = 0, startY = 0; let originX = 0, originY = 0; // 按下时记录起始位置和当前位移 group.addEventListener('mousedown', (e) => { e.preventDefault(); isDragging = true; startX = e.clientX; startY = e.clientY; // 解析当前transform const currentTransform = group.getAttribute('transform') || ''; const match = currentTransform.match(/translate\(([^,]+)[,\s]+([^\)]+)\)/); if (match) { originX = parseFloat(match[1]) || 0; originY = parseFloat(match[2]) || 0; } else { originX = 0; originY = 0; } document.addEventListener('mousemove', onMouseMove); document.addEventListener('mouseup', onMouseUp); }); function onMouseMove(e) { if (!isDragging) return; const dx = e.clientX - startX; const dy = e.clientY - startY; const newX = originX + dx; const newY = originY + dy; group.setAttribute('transform', `translate(${newX}, ${newY})`); } function onMouseUp() { isDragging = false; document.removeEventListener('mousemove', onMouseMove); document.removeEventListener('mouseup', onMouseUp); } })(); </script> </body> </html>这段代码的核心点有三个。第一，所有位移都写在transform里，path的d属性始终保持不变。第二，mousemove和mouseup监听在document上，保证拖动过程不会因为鼠标移出元素而中断。第三，通过正则解析已有的translate值，实现多次拖动的连续位移，而不是每次从初始位置跳变。
你可以直接把这个文件保存成html，浏览器打开就能玩。按下鼠标拖动，图形会平滑地跟随鼠标移动，松开后停留在新位置。再按一次继续拖，图形在上次基础上继续移动，不会跳回原点。
3.2 坐标转换的接入：不要被viewBox坑到
上面这段代码里，我直接用clientX的增量来计算translate。这种方式有一个前提：SVG没有经过缩放，且viewBox的宽度和SVG的实际CSS宽度是一致的。这种情况下，鼠标移动多少像素，图形就移动多少像素，直觉上是完全对得上的。
但在真实项目里，情况往往更复杂。你很可能设置了viewBox做自适应布局，比如：
<svg width="100%" viewBox="0 0 1000 600">此时SVG被浏览器拉伸成和父容器一样宽，内部坐标系与屏幕坐标的对应关系就变了。如果还直接拿clientX的增量去更新translate，图形移动的距离和鼠标移动的距离就会不一致。放大显示时，图形会“跟不上”鼠标；缩小显示时，图形会“超过”鼠标。用户体验非常诡异。
解决这个问题的关键，是把鼠标的屏幕坐标转换成SVG内部坐标再计算增量。改造后的代码逻辑如下：
function getSVGPoint(e) { const pt = svg.createSVGPoint(); pt.x = e.clientX; pt.y = e.clientY; return pt.matrixTransform(svg.getScreenCTM().inverse()); } group.addEventListener('mousedown', (e) => { const point = getSVGPoint(e); startX = point.x; startY = point.y; // ...其余逻辑不变 }); function onMouseMove(e) { const point = getSVGPoint(e); const dx = point.x - startX; const dy = point.y - startY; // ...更新transform }这样改动以后，无论SVG怎么缩放，图形的位移都和鼠标在SVG内部坐标系里的位移严格一致。你可能会说，我直接用clientX做增量在简单场景下也没问题啊。确实，但一旦你的页面同时存在滚动、缩放、移动端适配，问题就藏不住了。既然坐标转换的成本极低，写一劳永逸的版本永远是不二之选。
3.3 Pointer Events的统一处理
如果你只需要兼容PC端的鼠标操作，上面的方案就足够了。但现在的项目基本都要兼顾触屏设备。在手机上用手势拖动，touch事件和mouse事件的表现有差异，如果分开处理，代码量会翻倍。
更好的方案是使用Pointer Events。它把鼠标、触摸、触控笔统一成一套事件模型。你只需要把mousedown换成pointerdown，mousemove换成pointermove，mouseup换成pointerup，并加上setPointerCapture，代码本身几乎不用改。
注意一点：使用pointer事件后，要主动调用e.preventDefault()来阻止触摸滚动等默认行为，否则在手机上拖动时会触发页面滚动，和拖拽手势冲突。
完整改造的代码片段：
group.addEventListener('pointerdown', (e) => { e.preventDefault(); isDragging = true; const point = getSVGPoint(e); startX = point.x; startY = point.y; // ...解析当前位移 group.setPointerCapture(e.pointerId); }); group.addEventListener('pointermove', (e) => { if (!isDragging) return; const point = getSVGPoint(e); const dx = point.x - startX; const dy = point.y - startY; // ...更新transform }); group.addEventListener('pointerup', (e) => { isDragging = false; }); group.addEventListener('pointercancel', (e) => { isDragging = false; });setPointerCapture的作用是把后续的pointer事件全部重定向到当前元素上，即使你的手势划出了元素边界，事件也不会丢失。这一行代码，替代了之前“把监听器挂到document上”的笨办法，而且逻辑更清晰。
3.4 进阶：带动画内容的图形拖动
文章开头提到了鹈鹕骑自行车的动画，这是一个很适合用来说明“复杂SVG也能拖”的例子。假设你已经用SVG画好了一只鹈鹕骑自行车的动画，里面有多个path：车轮、车架、鹈鹕的身体、挥舞的翅膀等。
单独拖每一个path，显然不符合需求。用户希望的是，鼠标点住自行车的任何一个部分，整只鹈鹕带上自行车一起移动。
解决方案和前面讲的完全一样：把所有这些元素包在一个大g标签里，然后拖动这个g标签。结构上大概是：
<g id="whole-bike"> <g id="rear-wheel">...</g> <g id="front-wheel">...</g> <g id="pedal">...</g> <g id="pelican-body">...</g> <g id="pelican-wing">...</g> </g>拖动代码只需要针对id="whole-bike"这一个元素绑定事件。动画部分继续在内部跑——因为CSS动画或SMIL动画修改的是内部子元素，不影响外层g的transform。
这里有个非常关键的实现细节：如果内部动画是用CSS的transform做的，注意动画不要覆盖到外层这个g上的transform。正确的做法是，CSS动画只作用于更内层的标签，或者使用独立的动画属性，比如先把动画元素再包一层：
<g id="whole-bike" transform="translate(0, 0)"> <g style="transform: rotate(...)"> <path>...</path> </g> </g>把“用户交互位移”和“内部装饰动画”职责分离，是保证拖动顺畅、动画不打架的核心思路。
用一个实际的鹈鹕骑自行车SVG来演示，当整组拖动时，自行车车轮如果带旋转动画，它会在拖动过程中持续转动；鹈鹕的翅膀如果带上下摆动动画，它也会继续摆动。所有这些都发生在内部，外层g只是作为一个透明的“托盘”，负责承载整体位移。这个组合方式在真实项目中非常好用。
四个轮子、鹈鹕的翅膀、踏板这些细节，看起来复杂，但归根结底，它们都是这个大g的子元素。这一层抽象，是处理复杂SVG交互的关键钥匙。
4. 踩坑实录与性能优化技巧
4.1 鼠标指针和图形错位怎么办
很多人做完基础版本后发现：鼠标明明点的是图形的左上角，拖起来以后，图形左上角却突然“跳”到了鼠标位置，或者图形初始位置和鼠标之间有一段奇怪的偏移。
这个问题的根源是，mousedown开始时，记录的是鼠标位置和当前位移，但鼠标按下点不一定在图形的坐标原点上。比如图形原本在坐标系(100, 100)的位置，鼠标按下时在(180, 145)，这个位置对应图形内部点(80, 45)。如果不考虑这层偏移，直接用鼠标增量去更新图形位置，图形就会“跳”。
解决办法也不复杂，把按下时的鼠标位置和图形当前位置做差，计算出偏移量，然后在计算过程中补偿回去：
const offsetX = point.x - originX; const offsetY = point.y - originY; // 拖动时 const newX = point.x - offsetX; const newY = point.y - offsetY;这里的offsetX和offsetY，表示鼠标落在图形上时，相对于图形坐标原点的偏移。拖动过程中，始终保持图形左上角和鼠标之间的这个相对关系，图形就不会再乱跳。
4.2 拖到一半事件丢失，图形停住不动
这种现象在触屏设备上特别常见。手指在拖动，突然图形不动了，但后续touchmove事件还在触发。排查后发现，往往是touchmove在document层面的绑定没有被正确执行，或者被页面的滚动行为中断了。
使用Pointer Events后，这个问题基本被setPointerCapture根治了。只要在pointerdown时调用setPointerCapture，后续事件都会固定派发给当前元素，不管手指怎么移动，事件都不会丢。这是我在实际项目中最为推荐的处理方式。
另外还要注意CSS层面的问题，在拖动过程中给body加上user-select: none，防止快速拖动时浏览器把文本或图形选中，那也会导致事件分发出问题。
4.3 多次点击后位移偏移越积越大
有的实现会在每次mousemove时，直接基于上一次的transform值再做增量，而不是基于初始位移。这样会出现一个累积误差的问题：每拖动一次，误差就积累一次，拖了几次之后，图形位置就明显不对了。
正确做法是：只在mousedown时读取一次初始transform值，之后的mousemove全部基于这个初始值加鼠标增量，而不是在mousemove里反复读取、反复累加。这一点我在前面代码里已经体现出来了。若你发现图形越拖越漂，优先检查这一处。
4.4 拖动卡顿性能对比
提到性能，直接修改d属性和更新transform之间差距有多大，我用一个实际项目做过分母。一个包含约3000个坐标点、带大量贝塞尔曲线的path，直接解析并重写d属性，单次计算大约需要30-50毫秒。而更新transform的耗时可以忽略不计，在1毫秒以下。
如果你在拖动过程中还要做坐标转换，比如每次mousemove都调用getScreenCTM()，在宽松环境下这个开销也是可以接受的。但如果图形数量极多，比如同时拖动的有几十个元素，建议把getScreenCTM()的结果缓存起来，只在resize或画布缩放时重新计算。
4.5 还需要注意的杂项问题
第一，css的transform-box属性。如果某个path或者g标签上同时设置了CSS样式的transform，注意影响。SVG中的transform属性与CSS的transform属性处理原点的时候可能有差异。我的习惯是，交互位移用SVG的transform属性，动画和视觉变换用CSS，保持通道分离。
第二，多SVG实例的隔离。在页面上有多个独立SVG且都需要拖动时，事件监听器最好在svg内部边界隔离。不要把选择器写得太宽，避免点一个SVG的图形，另一个SVG也有反应。
第三，导出时的坐标规范化。如果做的是设计工具，导出的SVG里会带着一大坨translate。建议在导出前，把transform“烘焙”进path的d属性，也就是把位移值加到每个坐标点上去，然后清除transform。这样其他设计师拿到文件时，看到的就是干净、直接的坐标值，而不是一堆变换矩阵。
这里给出一个把translate烘焙进坐标的思路：
function bakeTransform(path, tx, ty) { const d = path.getAttribute('d'); // 用正则解析所有数字，通过标记判断是x还是y，分别加上偏移量 const newD = d.replace(/([+-]?\d+\.?\d*)/g, function (match) { // 需要考虑指令字符和参数顺序，这是一个简化示意 return (parseFloat(match) + (count % 2 === 0 ? ty : tx)).toFixed(2); }); path.setAttribute('d', newD); }这只是一个简化示意，真实实现需要按path命令分组解析，比如M、L、C、Q等指令后的参数位置。完整实现比较繁琐，但它解决的是“变换隔离”之后的规范性需求。
4.6 表格速查：三种常见拖拽实现方案对比
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 修改d属性 | 坐标直接写入，导出干净 | 性能差、语义混乱 | 图形锚点编辑，非整体拖动 |
| 更新外层g的transform | 性能好、语义清晰 | 导出前需要烘焙 | 整体拖动、组合图形拖动 |
| 使用CSS transform | 可以配合CSS动画 | 触发重新布局、受transform-origin影响 | 简单图形、装饰性动效 |
这是一张实用速查表。遇到具体的拖动需求，先判断应该用哪一类实现，能省下大量调试时间。
4.7 性能优化补充：requestAnimationFrame
在拖动过程中，如果图形非常复杂，或者mousemove事件的频次极高，你可以考虑用requestAnimationFrame做帧率控制。思路是：mousemove时只记录最新的目标位移值，但暂不更新DOM；在下一帧渲染时，统一把值写入transform。
这样能有效避免同一帧内多次重复的DOM写入，减少浏览器渲染压力。实测在生产环境里，对于复杂路径的拖动能明显提高帧率的稳定性。
示例逻辑：
let targetX = 0; let targetY = 0; let rafId = null; function onMouseMove(e) { targetX = originX + (e.clientX - startX); targetY = originY + (e.clientY - startY); if (rafId === null) { rafId = requestAnimationFrame(updateTransform); } } function updateTransform() { group.setAttribute('transform', `translate(${targetX}, ${targetY})`); rafId = null; }注意，这个优化方案在绝大多数项目里是可选的。如果只是拖动一两个path，直接更新transform已经足够流畅。但如果你的编辑器允许同时拖动多个复杂path，或者整体拖动的是超大矢量数据，这个优化就很有必要了。
5. 实战延伸：拖动与缩放、旋转的组合处理
SVG编辑器的交互，很少只有拖动这一个能力。图形还要支持缩放和旋转，此时，单纯一个translate就不够用了。transform属性支持组合变换，比如：
group.setAttribute('transform', `translate(${x}, ${y}) scale(${scale}) rotate(${angle})`);但要特别注意变换顺序。SVG的transform执行顺序是从右往左的，也就是说，上面的写法会先旋转，再缩放，最后平移。如果你把顺序写反，比如先translate再scale，那缩放就会以原点为基准，导致图形缩放后位置偏离预期。
组合变换的精确计算比较繁琐，尤其是鼠标点击位置和图形本地坐标之间的换算，涉及到矩阵乘法和逆矩阵。此时推荐直接引入矩阵计算库，或者使用SVG原生的DOMMatrix，它提供了比手工拼接字符串更强大和可维护的方式。SVGPathElement的transform属性是一个SVGAnimatedTransformList，借助它以及DOMMatrix，可以实现严谨的组合变换。
一个简单的旋转+拖动身份转换思路：
const ctm = group.getCTM(); const inverse = ctm.inverse(); // 再通过创建点反算鼠标在图形本地坐标中的位置这个思路足够支撑起一个基础图形编辑器。如果以后要做到像素级操控，比如自动对齐、辅助线吸附，那么在拖动时就要计算图形的包围盒bbox，与参考线做碰撞检测。所有这一切，都是建立在“拖动时更新transform”这个正确基础之上的。
另外，在实际使用过程中，我还遇到过一个有趣的问题：拖动的对象如果是一个被CSS缩放了的画布中的SVG元素，getScreenCTM()返回的矩阵会把CSS缩放也计算进去，所以反算出的SVG坐标是准确的。但是，如果你用getBoundingClientRect()做计算，就很容易出问题。这再次印证，SVG提供的矩阵转换API确实是处理这类拖拽的最终答案。
6. 最后再补充一点操作细节
很多人拷贝了代码之后跑通了，但觉得自己还是没有真正掌握这个功能的要领。我觉得，核心原因是没有建立起“分层”的观念。
做SVG交互，有三个层面：数据层、表现层、交互层。数据层保存path的原始d属性，它是图形的真正身份。表现层记录transform的变化，它是图形的状态。交互层负责把用户的操作翻译成状态变更。三者各司其职，代码就不会乱。
再强调一下，拖动一只鹈鹕骑自行车的复杂SVG，和拖动一个最简单的三角形path，用的逻辑完全是同一个。复杂度和图形细节无关，只和坐标变换的精度与事件处理的健壮性有关。把这个基础打牢，往后学到专业知识、做复杂编辑器，都会顺畅得多。
如果在实际项目中需要处理特别复杂的拖拽场景，比如路径点级别的编辑、橡皮筋框选、多点触控等，建议再深入了解一下DOMMatrix和SVG的底层API。先从这篇文章里的基础版本跑起来，再一步步迭代过去，比一开始就啃一堆复杂技术栈更稳。
