深入理解鼠标事件：坐标系、拖拽与性能优化实战

1. 从一次拖拽事故说起：坐标选错的代价

先讲个真实翻车经历。当时在给内部后台系统做一个可拖拽排序的卡片组件，卡片列表的容器为了做入场动画，加了transform: scale(0.9)的缩放效果。我按常规思路写拖拽：mousedown里记录起始点，mousemove里用e.clientX - startX算出位移，直接赋值给卡片的left和top。结果一拖起来，卡片像中了邪一样乱跳，鼠标往右拖，卡片却往右下飞，速度还越来越快。

排查了半天，问题出在坐标系上。clientX是相对浏览器视口的像素坐标，而卡片的left是相对父容器的坐标；父容器被transform缩放过，元素实际渲染位置和它的布局坐标根本不在一个空间里，直接拿视口坐标减偏移量去赋布局坐标，数据必然对不上。

这个事故给我最大的教训是：鼠标事件绝不是"加个onclick完事"那么简单。真正要掌握，得把几件事串起来看——事件类型和触发时机、坐标系换算、事件的传播顺序、按键状态判断、高频触发下的性能控制，以及移动端设备上鼠标事件和触摸事件的关系。这篇总结就是按这个思路整理的，适合刚接触前端事件处理的新人，也适合写过拖拽、画板、图表交互，但总在边界条件上翻车的初中级开发者。

我会尽量用实际代码和踩坑记录来讲，不堆抽象概念。

2. 鼠标事件家族：触发时机与兄弟关系

2.1 基础四兄弟：mousedown、mouseup、click、dblclick

鼠标事件不止click一个。mousedown在按下按键的瞬间触发，mouseup在松开按键的瞬间触发，click在同一个元素上完成"按下 + 松开"之后触发，dblclick则是连续两次快速click的产物。注意一个细节：如果按下和松开不在同一个元素上，click会在两个元素的最近公共祖先上触发。比如你在一个按钮上按下，滑到按钮外松开，click会落在按钮和外侧容器的共同父级上，而不是按钮本身。

最常见的误解是把click当成"按下"来用。做按钮的按下反馈动画时，不少人直接监听click，结果动画总在松开后才出现，手感很肉。正确做法是：按下反馈用mousedown，确认触发用mouseup或click。这两个事件的时机差异，在拖拽和绘制类交互里尤其关键，后面实战部分会详细展开。

dblclick也有一个隐蔽行为：每次双击，浏览器会先触发两次完整的click，再触发一次dblclick。如果你同时监听了click和dblclick，双击时单击逻辑也会被执行两次。解决思路一般是加一个延时标记，或者明确区分场景：需要单击响应的用click，需要双击响应的就忽略单次click的延时任务。

2.2 mousemove：触发频率远超你想的高

mousemove的触发机制很朴素：只要鼠标指针在元素上移动，就会持续触发。从 A 点移到 B 点，中间经过的每一个像素位置都可能触发一次事件。也就是说，鼠标划过一个 500 像素宽的容器，可能连续触发几百次mousemove。

这个特性决定了它不适合做重逻辑操作。比如在mousemove里实时查询getBoundingClientRect()，或者每次都做复杂的 DOM 样式读写，很容易把主线程卡到掉帧。性能优化章节会专门讲节流方案，这里先记住一句话：mousemove是高频事件，所有回调必须保持轻量。

2.3 mouseover / mouseout 与 mouseenter / mouseleave 的本质区别

这四兄弟是最容易混淆的一组。mouseover和mouseout会冒泡，而且触发规则是"进入或离开元素及其子元素"都要算；mouseenter和mouseleave不冒泡，只在鼠标真正进入或离开元素本身时触发。

举个例子：一个父容器里有一个子按钮。鼠标从父容器外面移到子按钮上，mouseover会触发两次——一次是进入父容器，一次是进入子按钮。而mouseenter只触发一次。反过来，鼠标从子按钮移到父容器其他区域，mouseout也会被触发一次，因为"离开了子按钮"。

所以如果你用mouseover做悬浮面板的显示逻辑，鼠标移到面板里的文字上时，面板可能会闪一下——因为进入子元素触发了mouseout。经典解法是改用mouseenter，或者判断event.relatedTarget是否仍是面板内部的元素。relatedTarget是这两个事件独有的属性：mouseover用它表示"从哪里来"，mouseout用它表示"到哪里去"。

2.4 contextmenu 与 wheel：容易被忽略的两个"近亲"

contextmenu在按下右键（或键盘菜单键）时触发，默认行为是弹出浏览器原生菜单。要自定义右键菜单，必须在contextmenu里调用preventDefault()。这个事件在实战中比想象中更常用，后面第 6 章会写完整的自定义菜单实现。

wheel是滚轮事件，它和mousewheel是两回事：mousewheel是老一辈浏览器的事件名，wheel是现代标准。监听滚轮时要注意，wheel事件的deltaY表示滚动距离，正值向下滚动。如果你想阻止页面滚动，需要preventDefault()，但前提是这个监听器必须标记为passive: false，否则浏览器会无视你的阻止请求。这个坑在性能优化章节会详细介绍。

3. 坐标系选择：clientX、pageX、screenX、offsetX

3.1 四种坐标到底代表什么

鼠标事件对象身上有四组坐标属性，区分起来其实不难：

打开控制台随便写个日志，把鼠标在页面不同位置移动，对比几组数值就明白了。多数交互场景只用得到clientX和offsetX。

这里要画一条重点线：clientX是视口坐标，页面滚动它不变；pageX是文档坐标，页面往下滚，pageY会变大。两者换算关系是pageX = clientX + window.scrollX。如果你要在绝对定位的浮层上放内容，一般用clientX加position: fixed；如果浮层是position: absolute且跟随文档滚动，就要用pageX。

3.2 offsetX 的兼容性阴影

offsetX是相对目标元素 padding 边缘的坐标，看起来很直觉，但它在部分浏览器里的实现存在差异——有的浏览器把它算成相对元素边框盒的坐标，有的算成相对 padding 盒。现代浏览器已经基本统一了语义，但如果你需要兼容很老的浏览器，不要依赖它做精确的像素级计算，改用手动换算：

canvas.addEventListener('mousemove', (e) => { const rect = canvas.getBoundingClientRect(); const x = e.clientX - rect.left; const y = e.clientY - rect.top; // 这里的 x, y 就是相对 canvas 内容区的坐标 });

这个写法的好处是逻辑透明：getBoundingClientRect()返回的是元素相对视口的实际渲染位置，拿clientX一减就是相对于元素左上角的坐标。注意rect.left是元素 border 外边缘的位置，如果元素有边框，减出来的坐标会比内容区偏大边框宽度，通常可以在样式上把边框去掉，或者再减去clientLeft。

3.3 回到开头的拖拽事故：坐标该怎么选

拖拽场景的正确姿势是：用clientX/clientY记录鼠标位置，用getBoundingClientRect()获取元素当前的实际位置，然后计算新的布局坐标。代码长这样：

const box = document.getElementById('box'); let startX = 0, startY = 0; // 按下时的鼠标坐标 let originLeft = 0, originTop = 0; // 按下时的元素位置 let dragging = false; box.addEventListener('mousedown', (e) => { if (e.button !== 0) return; // 只处理左键 dragging = true; startX = e.clientX; startY = e.clientY; const rect = box.getBoundingClientRect(); originLeft = rect.left; originTop = rect.top; }); document.addEventListener('mousemove', (e) => { if (!dragging) return; box.style.left = (originLeft + e.clientX - startX) + 'px'; box.style.top = (originTop + e.clientY - startY) + 'px'; }); document.addEventListener('mouseup', () => { dragging = false; });

为什么这样写就没错？因为这套逻辑里的所有数值都在同一个参考系里：originLeft是元素相对视口的位置，e.clientX - startX是相对视口的位移，相加结果仍然是视口坐标。只要元素 CSS 里用的是position: fixed，赋值后位置就完全吻合。如果你用的是position: absolute，那就得把originLeft换成相对于定位父级的坐标，这时候要么用offsetLeft，要么用getBoundingClientRect().left - 父级rect.left。

开头那个事故，就是因为父容器transform: scale()后，元素渲染位置和left布局值不再一致，我拿clientX的视口位移直接去加布局坐标，两边参考系不同，自然就乱跳了。

4. 事件传播链路：一次点击背后发生了什么

4.1 从 mousedown 到 click 的完整顺序

在同一个元素上完成一次左键点击，浏览器依次触发：mousedown→mouseup→click。双击则是：mousedown→mouseup→click→mousedown→mouseup→click→dblclick。

这个顺序是固定的，不随浏览器实现而变。所以如果你需要区分"单击"还是"拖拽"，可以在mouseup时判断位移量：位移小就是点击，位移大就是拖拽。这是很多组件判断点击和拖拽的标准做法。

还有一个容易忽略的点：click的触发不要求 mousedown 和 mouseup 在同一个元素上，但要求它们作用在同一个"最近公共祖先"范围内。如果你在 A 元素上按下、在 B 元素上松开，A 和 B 的共同父级会收到一个click事件。做事件委托时要注意这个情况，别以为click一定落在按下的那个元素上。

4.2 捕获、冒泡与事件委托

鼠标事件从触发开始，会先经历从window到目标元素的捕获阶段，再到目标元素本身，最后从目标元素一路冒泡回window。默认的addEventListener只监听冒泡阶段，想监听捕获阶段要传第三个参数true。

冒泡机制催生了事件委托：与其给每个子元素单独绑定，不如在父容器上绑定一次，用event.target找到实际点击的元素。配合closest()方法，代码非常干净：

document.querySelector('.list').addEventListener('click', (e) => { const item = e.target.closest('.item'); if (!item) return; // 点击的不是列表项 console.log(item.dataset.id); });

动态新增的列表项不需要重新绑定，天然就生效，这是事件委托最大的优势。递归组件的嵌套列表、菜单、表格行操作，都可以用这个模式。

4.3 stopPropagation 与 preventDefault 的正确边界

这两个 API 经常被混在一起用，但职责完全不同。stopPropagation()是阻止事件继续传播（冒泡或捕获），preventDefault()是阻止浏览器默认行为（比如右键菜单、文本选择、超链接跳转）。前者影响其他监听器，后者影响浏览器自身。

用stopPropagation()要非常克制。假设你在父级做了事件委托，子元素又单独绑了click且调用了stopPropagation()，父级的委托就失效了。很多线上 bug 就是这么来的。更安全的做法是：不阻止冒泡，在委托逻辑里判断target是否符合预期。只有在确实要隔离交互区域时才用stopPropagation()，比如弹窗内部的点击不应该触发遮罩层的关闭逻辑。

preventDefault()的边界坑更隐蔽。以拖拽为例：mousedown默认行为之一是可以选中文本，所以拖拽时常常需要在mousedown里调用preventDefault()来防止文本选中。但它有一个副作用——在某些情况下会影响focus行为，比如你拖拽一个输入框附近的元素，阻止默认后输入框可能拿不到焦点。这时更优雅的方案是用 CSS 的user-select: none配合-webkit-user-select: none，职责分离，副作用最小。

5. button 与 buttons：多键判断的细节

5.1 一个记录"触发键"，一个记录"当前按住的键"

event.button表示触发当前事件的按键编号，取值约定是：0左键，1中键（滚轮按下），2右键。event.buttons则是事件发生时有哪些键处于按下状态的位掩码：1表示左键，2表示右键，4表示中键。注意buttons里中键是 4，而button里中键是 1，很多人在这里踩坑。

buttons通常用于mousemove场景：判断拖动过程中是否仍按着左键。比如：

element.addEventListener('mousemove', (e) => { if ((e.buttons & 1) !== 0) { // 左键按着，说明在拖动 } });

位掩码的好处是支持组合判断：e.buttons === 3表示左右键同时按住。这在浏览器里是真实存在的场景，但实际业务中用得很少。

5.2 click 只认左键，右键走 contextmenu

一个经常被忽略的语义：click事件本身是给主键（通常是左键）定义的。右键点击在大多数浏览器里不会触发click，而是触发mousedown（button=2）→mouseup（button=2）→contextmenu。所以如果你的业务要区分左右键，不能只监听click，要在mousedown里判断e.button。

中键点击的情况更特殊：它会触发mousedown（button=1）→mouseup（button=1）→click，同时浏览器还有一个稍后触发的auxclick事件专门用来区分非主键的"点击"。如果你做的是类似标签页关闭按钮的交互，想统一响应左键和中键，click已经能覆盖，但想区分来源，就得监听auxclick或者直接看mousedown.button。

5.3 右键菜单与默认行为的冲突处理

自定义右键菜单的第一步就是让原生菜单不出现。很多初学者把preventDefault()写在mouseup或click上，发现没效果——因为原生菜单是contextmenu事件的默认行为。必须在contextmenu的回调里调用preventDefault()：

window.addEventListener('contextmenu', (e) => { e.preventDefault(); // 在这里显示自定义菜单 });

这个事件在浏览器窗口所有位置都会触发，包括空白区域。如果你只想在特定区域内显示自定义菜单，先preventDefault()再判断target是否在目标区域内，或者反过来：先用closest()判断命中，再决定是否preventDefault()。实测下来，后者的写法更稳妥，避免在无关区域白白销毁原生菜单。

6. 高频场景实战：拖拽、画板、右键菜单

6.1 拖拽：从能拖到拖得好

第 3 章已经给了基础版拖拽代码，但真正可靠的拖拽组件还差几个关键细节。

第一，mousemove和mouseup要绑在document上，而不是被拖拽元素上。因为鼠标一旦移动得比元素快，指针就可能滑出元素区域，绑定在元素上的事件会丢失，拖到一半就断。绑在document上，只要鼠标还在浏览器窗口内，事件就不会断。

第二，要处理拖拽后的"伪点击"。拖拽结束后，浏览器会触发一次click。如果你在click上绑定了展开详情之类的逻辑，拖拽松手时也会误触发。解法是记录拖拽位移，超过阈值就标记为拖拽：

let isDrag = false; box.addEventListener('mousedown', (e) => { startX = e.clientX; startY = e.clientY; isDrag = false; // 重置标记 }); document.addEventListener('mousemove', (e) => { const distance = Math.hypot(e.clientX - startX, e.clientY - startY); if (distance > 3) isDrag = true; // 超过 3px 就算拖拽 }); box.addEventListener('click', (e) => { if (isDrag) { e.stopPropagation(); // 拖拽后的 click 不继续传递 return; } // 正常的点击逻辑 });

第三，拖拽过程中要给元素加transition: none，拖完再恢复。否则 CSS 的过渡动画会让元素"追着"鼠标飘，看起来非常不跟手。

6.2 画板：把离散的点连成线

用 Canvas 做画板是mousedown+mousemove的典型应用。最 naive 的做法是每次mousemove都画一个点，但鼠标移动太快时，浏览器不会在每个像素都触发mousemove，点之间的距离会拉开，画出来是一串虚线。

解法是把上一个点和当前点用lineTo连起来：

const canvas = document.getElementById('canvas'); const ctx = canvas.getContext('2d'); let drawing = false; let lastX = 0, lastY = 0; canvas.addEventListener('mousedown', (e) => { const rect = canvas.getBoundingClientRect(); drawing = true; lastX = e.clientX - rect.left; lastY = e.clientY - rect.top; }); canvas.addEventListener('mousemove', (e) => { if (!drawing) return; const rect = canvas.getBoundingClientRect(); const x = e.clientX - rect.left; const y = e.clientY - rect.top; ctx.beginPath(); ctx.moveTo(lastX, lastY); ctx.lineTo(x, y); ctx.stroke(); lastX = x; lastY = y; }); canvas.addEventListener('mouseup', () => { drawing = false; });

这里要注意：getBoundingClientRect()每次事件都调用会有性能开销，高频mousemove下建议在mousedown时算好rect，之后直接用。另外，如果 Canvas 画布有 CSS 缩放，clientX - rect.left得到的是 CSS 像素坐标，还需要乘上canvas.width / rect.width才能映射到画布物理像素坐标，不然画出来的线位置是偏的。这个映射问题，几乎每个写画板的人都会踩一次。

6.3 自定义右键菜单：定位和边缘翻转

第 5 章说了拦截原生菜单，这里补齐完整实现。菜单通常是position: fixed的浮层，坐标直接用clientX/clientY：

const menu = document.getElementById('menu'); window.addEventListener('contextmenu', (e) => { const isTarget = e.target.closest('.custom-area'); if (!isTarget) return; e.preventDefault(); const menuWidth = 150; const menuHeight = 200; let x = e.clientX; let y = e.clientY; // 防止菜单超出视口 if (x + menuWidth > window.innerWidth) { x = window.innerWidth - menuWidth; } if (y + menuHeight > window.innerHeight) { y = window.innerHeight - menuHeight; } menu.style.left = x + 'px'; menu.style.top = y + 'px'; menu.style.display = 'block'; }); window.addEventListener('click', () => { menu.style.display = 'none'; });

边缘翻转的逻辑很简单：菜单的右边和底边不能超出视口。如果鼠标在视口右下角，菜单就要从鼠标位置往左上翻。另外，关闭菜单不只是click，还有keydown（比如 Esc）和滚动事件，漏掉任何一个都会造成菜单残留。滚动关闭尤其容易被忘，因为页面有滚动条时，用户滚动后菜单还停在原地，就会产生"菜单飞了"的错觉。

7. 性能优化：mousemove 是最大的敌人

7.1 为什么不能放任 mousemove

一个老老实实的mousemove监听器，鼠标扫一圈可能触发上百次回调。如果回调里做了getBoundingClientRect()、修改了多个元素的样式、触发了一次布局抖动，性能损耗是累积的。你会在任务管理器里看到浏览器 CPU 飙升，页面滚动卡顿。

最基础的优化是节流（throttle）：保证一定时间窗口内回调只执行一次。比如每 50ms 执行一次，一秒最多 20 次，肉眼完全分辨不出差别，CPU 消耗却能降一个量级。

let lastCall = 0; const THROTTLE_MS = 50; window.addEventListener('mousemove', (e) => { const now = Date.now(); if (now - lastCall < THROTTLE_MS) return; lastCall = now; // 更新 UI 的逻辑 });

7.2 requestAnimationFrame：和屏幕刷新对齐

节流有个问题：它按固定时间切割，可能刚好卡在两次屏幕刷新之间，造成视觉上的一顿一顿。更优雅的方案是用requestAnimationFrame（简称 rAF）。rAF 的回调会在每次屏幕刷新前执行一次，也就是说它和浏览器的绘制节奏完全同步，这是处理高频事件的最佳姿势：

let ticking = false; window.addEventListener('mousemove', (e) => { if (ticking) return; ticking = true; requestAnimationFrame(() => { // 拿 e.clientX / e.clientY 更新 UI updateUI(e.clientX, e.clientY); ticking = false; }); });

注意这里有个细节：e在 rAF 回调执行时仍然可以读取，因为事件对象在事件循环结束前不会被销毁。实测下这个方案比固定节流更跟手，因为它在刷新边界上工作，永远不会产出"跳帧"的感觉。

7.3 事件解绑与监听器数量控制

性能优化不只是降频。事件绑定后不清理，组件销毁时监听器还挂在全局，内存泄漏的风险就来了。特别是 SPA 场景，页面切换不刷新，全局监听器越积越多，最终所有页面都变卡。

规范做法是在组件卸载时解除绑定。手动绑定的事件，记录引用，卸载时removeEventListener。用事件委托的话，尽量把监听器绑在就近的容器上而不是全局，这样容器销毁时监听器也随之释放。还有一个小技巧：需要全局监听的事件（比如拖拽时的mousemove和mouseup），不要在初始化时绑定，而是在mousedown触发时绑定，mouseup触发时解绑。这样平时全局没有任何多余的监听器，性能最干净：

box.addEventListener('mousedown', (e) => { document.addEventListener('mousemove', onMove); document.addEventListener('mouseup', onUp); }); function onUp() { document.removeEventListener('mousemove', onMove); document.removeEventListener('mouseup', onUp); }

这个模式唯一的代价是每次拖拽都要绑定解绑，开销极小，换来的是"非拖拽状态下零全局监听"的收益，非常划算。

8. 触摸设备与 Pointer Events：跨端兼容的现代方案

8.1 触摸事件如何伪装成鼠标事件

在触摸屏上，浏览器收到触摸操作后，会额外合成一组鼠标事件来兼容旧页面。一次手指点击，典型顺序是：touchstart→touchend→mousemove→mousedown→mouseup→click。mouseover和mouseenter之类的事件也可能被触发。

这对桌面端页面没什么影响，但如果你在移动端做画板或拖拽，就会出现问题：手指拖动时，touchmove和合成的mousemove会同时触发，逻辑执行两遍，坐标还不一样。经典解法是在touchstart里调用preventDefault()，阻止浏览器合成鼠标事件：

canvas.addEventListener('touchstart', (e) => { e.preventDefault(); // 阻止合成鼠标事件 // 用 e.touches[0].clientX 处理触摸 }, { passive: false });

这里passive: false是必须的。现代浏览器默认把touchstart和touchmove标记为 passive，意味着回调里不能preventDefault()，如果你不加这个选项，写了preventDefault()也会被忽略，控制台还会打警告。

8.2 Pointer Events：把鼠标和触摸统一起来

与其同时维护鼠标和触摸两套逻辑，不如直接用 Pointer Events。这套 API 用一个事件名覆盖所有输入设备：pointerdown、pointermove、pointerup、pointerenter、pointerleave分别对应鼠标那一套。事件对象上有pointerType属性，值是mouse、touch或pen，可以按需分流：

canvas.addEventListener('pointerdown', (e) => { if (e.pointerType === 'mouse' && e.button !== 0) return; const x = e.clientX - rect.left; const y = e.clientY - rect.top; // 统一处理 }); canvas.addEventListener('pointermove', (e) => { // 逻辑和鼠标版一致 });

Pointer Events 还提供了setPointerCapture()方法，可以在pointerdown时把后续的pointermove/pointerup都重定向到当前元素上，即使指针滑出元素范围也不会丢事件。这个特性比"把事件绑到 document 上"更优雅，因为它天然隔离了多个拖拽元素之间的干扰：

canvas.addEventListener('pointerdown', (e) => { canvas.setPointerCapture(e.pointerId); // 后续 pointermove / pointerup 都会派发到 canvas 上 });

现代浏览器的支持度已经足够，桌面和移动端都能用。如果你维护的页面还在服务很老的内核，那才需要退回到鼠标事件 + 触摸事件双轨写法的老路。

8.3 实际项目里怎么选

如果项目只面向桌面端，直接写鼠标事件没问题，代码最少，心智负担小。如果目标设备包含平板和手机，建议从现在的新功能开始用 Pointer Events，老功能逐步迁移。这里有个实践建议：把事件处理抽成一个薄薄的统一层，内部封装"取坐标"和"判断按键"两个函数，后续不管是鼠标、触摸还是笔输入，业务代码都不需要改。

9. 调试技巧与高频坑位清单

9.1 快速定位事件问题的方法

遇到鼠标事件行为异常，第一件事是把事件对象完整打印出来，看坐标、目标元素和按键状态。可以直接在全局监听：

window.addEventListener('click', (e) => { console.log(e.clientX, e.clientY, e.target); console.log(e.target.getBoundingClientRect()); });

这样能快速确认两个关键问题：事件到底落在哪个元素上？坐标数值是否符合预期？特别是e.target，很多 bug 都源于"我以为点的是 A，实际点的是 A 里面更深的子元素"。

如果事件压根没触发，先查三件事：元素是否被遮挡（其他元素盖在上面）、事件是否被stopPropagation()截断、是否绑到了错误的元素上。用浏览器调试器的"事件监听器"面板，能直接看到某个元素上注册了哪些监听器，比盲猜快得多。

9.2 高频坑位清单

把这几年的踩坑经验汇总成一张表，每一条都是真实线上问题：

9.3 一个通用的调试小工具

我习惯在项目里留一个简单的工具函数，开发环境下随时打印鼠标事件的关键信息：

function traceMouseEvents(selector) { const el = document.querySelector(selector); ['mousedown', 'mouseup', 'click', 'mousemove', 'mouseenter', 'mouseleave'].forEach((type) => { el.addEventListener(type, (e) => { console.log(`[${type}]`, { target: e.target.className, clientX: e.clientX, clientY: e.clientY, button: e.button, buttons: e.buttons }); }); }); }

正式排查时，开着这个工具拖动或点击，看事件触发的顺序和数量，五分钟内就能定位大多数问题。尤其是事件没触发和触发次数异常这两类问题，日志一打就能看出端倪。

回到文章开头那个transform缩放事故，后来我把拖拽的逻辑整体换成了clientX+getBoundingClientRect()的坐标体系，并且封装了统一的取坐标函数，从那以后再也没有出现过"乱跳"的拖拽组件。我个人做前端交互这十多年的体会是：鼠标事件本身不难，难的是把坐标系、事件顺序、默认行为、性能频率这些底层规律全部串起来理解。把这些基础吃透，写任何交互组件心里都有底。