很多人在做手绘板、签名板、批注工具、白板协作这类交互时第一个卡住的点不是怎么画线而是怎么画出一条看着舒服的半透明线。表面上看就三行代码监听鼠标、moveTo、lineTo、stroke。但真跑起来你会发现一堆问题——线是硬邦邦的折线快速划动会断成一节一节颜色越描越深在高分屏上模糊得像加了滤镜移动端一碰页面就跟着滚。我用 canvas 做过好几轮类似的涂鸦交互从最简单的鼠标轨迹到支持触控笔的批注层中间踩的坑基本都集中在透明度和重绘策略这两件事上。下面就把整条链路拆开讲清楚为什么要这么设计、参数怎么定、坑在哪、怎么验证。1. 透明线条的观感从哪来先定视觉目标再写代码动手之前得先回答一个问题你要的透明是哪一种透明是整条线从头到尾均匀地淡还是像马克笔一样叠涂会加深这两者的实现路径完全不同选错了后面越写越别扭。均匀淡适合做批注、草图、参考线视觉上干净叠涂加深适合做涂鸦、荧光笔、水彩感用户来回涂抹会自然形成深浅层次。前者要求整笔像素只被绘制一次后者恰恰要允许重复叠加。1.1 三种让线变淡的做法效果和代价完全不同globalAlpha、rgba()颜色、shadowBlur柔边是最常见的三条路。它们不是等价的替代品细节差别很大。globalAlpha作用于整个上下文的所有绘制操作包括线条、填充、文字。设置一次ctx.globalAlpha 0.15之后之后所有stroke()都按这个比例混合。它的好处是改一个数就能整体调坏处是它是个状态容易被别的地方覆盖——你在某个函数里设了 0.9 画别的元素忘了改回来下一笔就是 0.9 而不是 0.15。我现在的习惯是涉及globalAlpha的代码进入和退出时成对写或者干脆只在绘制函数内部临时设置、用完立刻还原。rgba(60, 120, 255, 0.15)写在strokeStyle里粒度更细可以每一笔用不同颜色不同透明度互不干扰。涂鸦场景我更推荐这个因为用户往往会换颜色用globalAlpha等于给自己埋了一个全局状态炸弹。shadowBlur配合shadowColor可以做出边缘晕开的柔和感看起来像荧光笔或者喷枪。代价很直接阴影是绘制管线里最耗性能的一环之一线一多帧率掉得肉眼可见。除非你就是要那种朦胧效果否则别在连续绘制的热路径上用。方案均匀性状态污染风险性能适用场景globalAlpha均匀高全局状态好整层统一透明度rgba()颜色均匀低随笔画走好多色涂鸦、批注shadowBlur柔边边缘发散低差荧光笔、光效还有一个容易被忽略的点lineWidth和透明度是联动的。同样是 0.15 的透明度2px 的细线看着是淡淡的铅笔痕20px 的粗线看着像一块半透明的色块因为粗线覆盖的像素多视觉权重高。所以调透明度的时候别孤立地调要跟线宽一起试。1.2 低透明度叠加会越涂越实是特性也是坑这是透明涂鸦最核心的视觉特性必须提前想清楚。当你用 0.1 的透明度在同一位置反复描边每次混合都会让结果更接近不透明画一次是 10% 的色画两次大致是 19%画五次接近 40%画十次就基本实了。这个数学关系是指数收敛的不会超过 100%但收敛得很快。用户的行为模式决定了这是好事还是坏事。如果用户是在做涂鸦来回涂抹本来就是预期动作越涂越浓正是他想要的跟真的马克笔一样。但如果用户是在做签名字迹或者高亮标记他只想划一笔结果手抖在同一个地方抖了两下颜色突然深一块看着就很脏。判断标准其实很简单看你的场景里重复经过同一点是不是用户意图。是 → 保留叠加不是 → 就必须保证每个位置只被绘制一次。后者听起来简单实际很难因为线段之间的抗锯齿边缘天然会重叠圆头线帽lineCap: round在相邻线段连接处的重叠面积更大即使同一笔连续画连接点也容易出现一连串略深的小鼓包。一个实用的缓解手段是把整笔当作一条完整路径来描边而不是一段一段描边。ctx.beginPath()之后把所有点lineTo下来最后只stroke()一次浏览器会把整条路径作为一个整体做抗锯齿连接处就不会有重复混合。但这跟每来一个点就立刻显示的实时反馈是有冲突的解决方案是分层后面第 4 节会详细讲。2. 坐标对不上像素比与画布尺寸的换算关系线画歪了、位置偏了、在高分屏上糊了十有八九是坐标换算没理清。这块内容老生常谈但每次换项目还是会有人栽进去因为它牵涉三套彼此独立的数字CSS 布局尺寸、画布缓冲区尺寸、设备像素比。2.1 canvas.width 与 CSS width 是两套数字canvas width800 height600这个width属性是绘制缓冲区的像素数量不是显示尺寸。如果你在 CSS 里写canvas { width: 100%; }那显示尺寸由布局决定跟缓冲区尺寸就没关系了。浏览器会把缓冲区拉伸铺满显示区域于是 800 像素的内容被拉成 1200 像素宽自然就模糊了。正确做法是让缓冲区尺寸跟显示尺寸 × 设备像素比对齐。假设容器宽 600 CSS 像素设备像素比是 2缓冲区就应该是 1200 像素然后通过setTransform把绘制坐标系缩回 600这样你写代码时依然按 CSS 像素思考输出却是清晰的。function setupCanvas(canvas) { const dpr window.devicePixelRatio || 1; const rect canvas.getBoundingClientRect(); canvas.width Math.round(rect.width * dpr); canvas.height Math.round(rect.height * dpr); const ctx canvas.getContext(2d); // 把坐标系重新映射到 CSS 像素 ctx.setTransform(dpr, 0, 0, dpr, 0, 0); return ctx; }这里有个必须记住的副作用给canvas.width或canvas.height赋任何值哪怕是相同的值都会清空整个画布并重置所有上下文状态——strokeStyle、lineWidth、lineCap、globalAlpha、变换矩阵全部回到默认。所以setupCanvas之后必须重新配置一遍绘制状态。我见过不止一次改完窗口大小线就变黑色细线的问题根因就是这个。另外setTransform和scale的区别要分清。scale是累乘的调两次 2 倍就变成 4 倍setTransform是覆盖式的每次都从单位矩阵重新开始。窗口尺寸变化可能触发多次重设用setTransform才不会越缩越小。2.2 取点用 getBoundingClientRect 而不是 offsetXevent.offsetX看着方便但它的语义是相对于事件目标内边距边缘的偏移一旦 canvas 上有 CSS 变换比如缩放、旋转、或者目标元素是 canvas 内部的子元素、或者页面滚动状态特殊offsetX就可能不准。跨浏览器的一致性也不如clientX稳定。更稳的写法是拿clientX/clientY减去getBoundingClientRect()的左上角function toCanvasPoint(canvas, e) { const rect canvas.getBoundingClientRect(); return { x: e.clientX - rect.left, y: e.clientY - rect.top }; }因为前面已经把上下文坐标系映射成了 CSS 像素所以这里算出来的值可以直接拿去moveTo。如果 canvas 有 CSS 缩放transform: scale(0.8)getBoundingClientRect()返回的是缩放后的尺寸而canvas.width是按缩放前的布局算的这时候还得再除以缩放系数。要做严格正确的话用rect.width / canvas.offsetWidth算出实际缩放比再乘回去。getBoundingClientRect()会触发一次布局计算在pointermove里每帧调用几十次是有成本的。优化方式是缓存在pointerdown时取一次scroll和resize时失效重取。对绝大多数场景来说每次调用也不会卡但如果你在做 120Hz 高刷屏加高频笔输入的场景就该考虑缓存了。还有一个隐藏的边界问题指针坐标可以略微超出画布范围比如指针压在画布边缘外一点点但事件还绑在 document 上这时候画出来的线会跑到画布外面被裁掉看起来像线突然消失。用setPointerCapture把指针锁在画布上行为会更可预期。3. 从离散点到一笔顺滑的线鼠标移动事件是离散采样每秒几十到两百个点。直接把这些点用lineTo连起来就是一条由直线段拼成的折线。慢速移动时点密看着还行快速划动时点稀折角立刻明显。这是涂鸦手感差的最直接原因。3.1 采样距离阈值决定手感和性能很多人第一反应是那我把所有点都记下来画但这样会带来两个问题一是密集度太高快速小幅度抖动会累积大量几乎重合的点白白增加开销二是点太密时相邻点距离小于一个像素lineTo画出来的短线段会把圆头线帽反复叠加形成一条斑驳的粗边。所以要设一个最小距离阈值距离上一次记录的点太近就丢弃const MIN_DIST 1.5; // CSS 像素 function shouldSample(last, cur) { const dx cur.x - last.x; const dy cur.y - last.y; return dx * dx dy * dy MIN_DIST * MIN_DIST; }用平方比较省掉开方是个小优化但很实用。阈值的取值有讲究1 像素以下基本等于不过滤点会爆炸3 像素以上快速划动时会出现明显的跳点感线段拐角变硬。1.5 到 2 之间是比较舒服的区间具体看你线宽——线宽越粗阈值可以略大一点因为粗线的视觉容错度高。阈值还有个副作用值得说它会让起点附近的一小段缺失。用户按下鼠标之后可能微移了几个像素才触发第一次采样线头就少了一截。解决办法是在pointerdown时无条件记一个点后续移动才走阈值过滤这样线头一定是准的。3.2 中点二次贝塞尔把折角磨圆有了采样点接下来是把折线变曲线。最常用的是中点法不把原始点当作曲线经过点而是把相邻两点的中点当作端点原始点当作控制点用quadraticCurveTo连接。function mid(a, b) { return { x: (a.x b.x) / 2, y: (a.y b.y) / 2 }; } // 假设 points 是采样点数组只画新加入的一段 function drawSegment(ctx, p0, p1, p2) { const m1 mid(p0, p1); const m2 mid(p1, p2); ctx.beginPath(); ctx.moveTo(m1.x, m1.y); ctx.quadraticCurveTo(p1.x, p1.y, m2.x, m2.y); ctx.stroke(); }原理很直观贝塞尔曲线不经过控制点所以让原始采样点做控制点曲线就会在它附近贴边滑过去天然把尖角磨掉。代价是曲线会比原始轨迹稍微内切一点转角大的地方看起来有点像抄近道。手绘涂鸦对这个不敏感但如果是在画多边形或者描边标注就得考虑用 Catmull-Rom 样条它保证曲线经过每个控制点代价是计算量更大。增量绘制时要注意起点的衔接。上面drawSegment每次从m1开始到m2结束下一段从m2开始端点正好对上不会断。但如果中间丢了点比如阈值过滤掉了衔接就会出现小缺口被lineCap: round的圆头盖住一般看不出来。3.3 线帽线接与速度模拟笔锋lineCap和lineJoin两个属性对透明线条的观感影响比想象中大。lineCap: butt是方头截断相邻线段之间会有 V 形缺口在粗线上特别明显像一串被剪断的香肠。lineCap: round是圆头能盖住缺口但在低透明度下重叠区域的抗锯齿会让连接点略深形成糖葫芦效果。lineJoin: round处理的是折角外侧避免尖角过冲。我的默认配置是圆头圆角除非发现连接点明显发深才改策略ctx.lineCap round; ctx.lineJoin round; ctx.miterLimit 2; // 尖角保护防止极端角度产生长刺想要更像真笔触可以按移动速度动态调线宽速度快的段落细慢的段落粗因为真人运笔时快写会提笔。实现方式是用相邻点距离除以时间差function speedToWidth(distance, dt, base 6) { const v distance / Math.max(dt, 1); // px/ms const factor Math.min(1.6, Math.max(0.4, 1.4 - v * 0.6)); return base * factor; }这个技巧在小尺寸涂鸦上很出彩但要注意线宽变化会在段与段之间产生台阶需要配合平滑过渡比如对宽度做指数移动平均否则看着像竹节。对支持压感的设备event.pressure能拿到 0 到 1 的压力值直接用最省事。但要注意鼠标事件的pressure通常固定是 0.5按下时或 0未按下并不是真的压力所以得先看pointerTypepen用压力mouse用固定宽度或速度模拟。4. 增量描边还是全量重绘透明度的账要算清这是整个实现里最容易写错、也最难自己发现的一块。写错了画面不会报错只是颜色悄悄变深或者帧率随着笔画变多线性下降等你反应过来已经改了一大片代码。4.1 每次 move 都重绘整条路径会导致颜色累积很多人第一版是这么写的canvas.addEventListener(pointermove, (e) { const p toCanvasPoint(canvas, e); ctx.lineTo(p.x, p.y); ctx.stroke(); // 每次 move 都把整条路径重新描一遍 });用不透明颜色时看不出问题因为后画的完全覆盖先画的。一旦透明度小于 1问题就暴露了每来一个新点之前画过的所有线段都被重新描一次第 100 个点进来时最早那段线已经被描了 100 次直接变成实心。视觉上就是线头深、线尾浅像一支边画边干的笔。正确的增量做法是每段只描一次let last null; function onMove(p) { if (!last) { last p; return; } ctx.beginPath(); ctx.moveTo(last.x, last.y); ctx.lineTo(p.x, p.y); ctx.stroke(); last p; }配合前面的中点平滑就是beginPath → moveTo(上一段终点) → quadraticCurveTo → stroke每次只在画布上新增一小块不碰已经画好的部分。但增量方案有个副作用如果某一笔想改变样式比如用户中途调了透明度已经画上去的部分改不回来了。所以增量方案适合一笔一色的固定样式动态样式要另想办法。4.2 分层画布完成笔画与活动笔画分离当你既想要透明度一致又想要实时反馈还想要元素能被修改或撤销单画布就不够用了。分层是标准解法一张底层画布存已经完成的笔画一张顶层画布存正在画的那一笔。顶层每帧整个擦掉重画当前这一笔的完整路径。因为一笔的点数有限通常几百个全量重绘完全扛得住而且整条路径只被stroke()一次透明度绝对均匀连接处不会有叠加发深。松手时把顶层的内容用drawImage合到底层然后清空顶层开始下一笔。const layer document.createElement(canvas); const lctx layer.getContext(2d); function commitStroke(baseCtx) { baseCtx.drawImage(layer, 0, 0, layer.width, layer.height, 0, 0, baseCtx.canvas.width / dpr, baseCtx.canvas.height / dpr); lctx.clearRect(0, 0, layer.width, layer.height); }注意drawImage的尺寸参数。如果底层和顶层都按设备像素比设置了缓冲区合的时候要按 CSS 尺寸绘制否则会画成两倍大。这也是个常见错误症状是笔画合过去之后位置和粗细全不对。三层的结构背景底图、已完成笔画层、活动笔画层在批注类场景很常见底图不动笔画层累积活动层高频刷新。每层都独立清空重置互不干扰性能也比每次全量重绘好得多。还有一个替代思路是把所有笔画存成矢量数组每帧遍历全部重绘。点数少的时候看着很优雅因为样式随时可改、撤销也简单。但涂鸦场景的点数增长很快一笔几千点、几十笔就是十几万次路径操作帧率必崩。我的经验阈值是总点数低于 5000 可以全量重绘超过就得转增量或分层。方案透明度均匀性实时性可编辑性点数上限全量重绘好稍差好约 5000 点增量描边好单段好差高分层画布好好中高5. 高频输入下的性能与内存指针设备的采样率已经很高了普通鼠标 125Hz游戏鼠标 1000Hz触控笔和触屏能到 240Hz 甚至更高。每个pointermove都同步画一次等于把绘制压力直接绑在了输入频率上。桌面端可能只是风扇变响移动端就是肉眼可见的卡顿和发热。5.1 requestAnimationFrame 合批与 getCoalescedEvents最有效的降载手段是把接收输入和绘制输出解耦。指针事件里只做一件事把点攒进队列。真正的绘制放到requestAnimationFrame里一帧只画一次。const queue []; let rafId 0; let last null; canvas.addEventListener(pointermove, (e) { queue.push(toCanvasPoint(canvas, e)); if (!rafId) rafId requestAnimationFrame(flush); }); function flush() { rafId 0; if (!queue.length) return; // 一次性处理这一帧攒下的所有点用折线或平滑连接 for (const p of queue) { if (last shouldSample(last, p)) { drawSegment(last, p); last p; } } queue.length 0; }这样 1000Hz 的鼠标在 60Hz 屏幕上每帧也就处理十几个点而不是 16 次独立绘制。省下来的不只是stroke时间还有每次绘制触发的合成开销。getCoalescedEvents()是另一个方向的优化。浏览器为了性能会把高频事件合并一个pointermove可能对应了多个物理采样点。调用e.getCoalescedEvents()能把这些被合并的点全拿回来让曲线在快速划动时更细腻。注意它在部分环境下拿到的点可能包含与上一个事件重复的点用之前最好做一次去重或距离过滤。const raw e.getCoalescedEvents ? e.getCoalescedEvents() : [e]; for (const ev of raw) { queue.push(toCanvasPoint(canvas, ev)); }代价是点数变多绘制压力上升。所以我的建议是只在pointerType pen或者检测到高刷新率设备时才启用鼠标场景收益不大。还有一个容易被忽略的性能杀手ctx.shadowBlur、ctx.filter、以及超大尺寸画布。画布缓冲区如果是 4000×3000 这种尺寸每次清空和合成都得处理上千万像素再怎么优化事件也没用。画布尺寸应该跟可见区域对齐不要为了可能要看大图就搞一个巨大的缓冲区。5.2 点数组的增长、裁剪与撤销栈维护撤销功能就得存历史。最省内存的做法是存笔画 点数组 样式而不是每笔存一张ImageData。一个 1000×800 的ImageData是 3.2MB存二十步就是 64MB移动端直接给你干掉。点数组一秒存几十个点一笔几千点才几十 KB差了三个数量级。存点数组的代价是撤销时要重新绘制。做法是清空已完成的笔画层把除最后一笔外的所有笔画按顺序重放一遍。笔画多的时候重放会有一瞬间的卡顿视觉上像闪一下。缓解手段有两个一是限制撤销步数比如 20 步二是重放时不走逐点绘制直接把每条笔画用moveTo/bezierCurveTo拼成完整路径一次stroke。如果只需要清空全部而不需要逐步撤销那就简单得多clearRect一把梭连历史都不用存。很多批注场景其实就是这样用户真正想要的是一键清屏而不是撤回三次。另外别忘了给点数组做上限保护。有些用户会在同一个位置疯狂抖动鼠标十几秒就能攒下几万个几乎重合的点。加个硬性上限比如单笔 8000 点超了就丢弃新点配合距离过滤基本能兜住极端情况。6. 收尾工作指针中断、清空、导出与踩坑复盘画线的主体逻辑跑通之后剩下的都是收尾细节。这部分代码量不大但漏一处就会出一次线上问题而且往往是小概率、难复现的那种。6.1 指针离开与窗口失焦的收线pointerup是最常见的结束信号但它不是唯一的。用户可能在画到一半时切换了窗口、按了浏览器快捷键、或者把指针拖出了画布。如果只监听pointerup就会出现线一直连着鼠标的诡异状态松手了但画笔没收之后移动鼠标还在画。完整的事件集合是pointeruppointercancelpointerleave 窗口blur。其中pointercancel在移动端特别重要系统手势介入、来电、通知下拉都会触发它专门用来告知这个指针序列被系统抢走了。如果不处理移动端很容易残留一条画了一半的线。用setPointerCapture(e.pointerId)可以让指针在移出画布后依然把事件发给画布配合pointerup释放能把移出边界的情况统一到正常流程里。但要注意捕获之后pointerleave的语义会变化两者同时用容易理不清我一般二选一要么用捕获 pointerup要么不用捕获 监听pointerleave收线。移动端还有两个必做项。一是 CSS 加touch-action: none让浏览器不要把手势解释成滚动或缩放这个属性写在 canvas 上比在事件里preventDefault更干净也更可靠。二是user-select: none和-webkit-touch-callout: none防止长按弹出菜单打断绘制。canvas { touch-action: none; user-select: none; -webkit-user-select: none; -webkit-touch-callout: none; display: block; /* 消除 inline 元素底部的空白间隙 */ }display: block这行看着无关紧要但它能消除 canvas 作为行内元素时底部的字体基线空隙避免容器尺寸和画布尺寸差几个像素导致坐标整体偏移。这种几个像素的偏差在粗线上不明显在 1px 细线上就会让整条线糊成一片。6.2 清空、撤销与导出透明 PNG清空看着就是clearRect但要注意变换矩阵。如果上下文有setTransform(dpr, ...)那clearRect(0, 0, cssWidth, cssHeight)就够了因为坐标系已经是 CSS 像素。但如果中途某处重置过 transform就得按缓冲区尺寸清否则会清不干净边缘留一条残影。导出图片时最容易踩的是格式。toDataURL(image/png)会保留透明背景toDataURL(image/jpeg)会把透明区域填成黑色因为 JPEG 没有 alpha 通道。要导出带背景色的图片得先画一层底色再导出function exportWithBackground(source, bgColor #ffffff) { const out document.createElement(canvas); out.width source.width; out.height source.height; const octx out.getContext(2d); octx.fillStyle bgColor; octx.fillRect(0, 0, out.width, out.height); octx.drawImage(source, 0, 0); return out.toDataURL(image/png); }还有一点如果用了分层画布导出时得先把所有层合成到一张临时画布上再导别指望导出来的图自带叠加效果。6.3 几个反复踩到的具体问题快速划动变成折线。根因通常是采样点太少或者平滑参数不对。先确认getCoalescedEvents有没有开再检查距离阈值是不是设太大超过 3 像素时快速划动必然段数不够最后看中点法的插值是否生效。还有一种可能是绘制被rAF合批之后一帧内攒了几十个点却只用首尾两点连线那就丢掉了中间的弯曲信息得在 flush 里逐段处理而不是只取首尾。改了窗口大小之后画面全白。这是canvas.width赋值清空画布的经典症状。要么把已有内容在 resize 前用drawImage存下来再贴回去要么把笔画数据重放一遍。要注意 resize 事件触发很频繁得节流否则一边拖窗口一边重放几十笔画直接卡死。我一般用 100ms 的防抖等用户松手再重排。连接处出现一串深色小圆点。这是分段描边 圆头线帽在低透明度下的重叠痕迹。最直接的解法是换成整笔重绘的活动层其次是改用butt头再手动在连接处补一个极小的矩形填充麻烦不推荐。如果是中点法导致的检查一下相邻两段曲线的端点是否真的重合坐标取整时的误差会让端点差半个像素抗锯齿叠加就显形了。移动端一碰就跟着滚页面。touch-action: none没加或者加在了父元素上而没加在 canvas 上。另外 iOS 上还要注意pointermove在某些情况下会被系统手势打断pointercancel一定要处理否则会残留半个笔画。线在画布边缘消失。如果指针移出了 canvas 但事件还绑在 document 上坐标会超出画布范围stroke出来的部分被裁掉。用setPointerCapture把指针约束在画布内或者手动把坐标钳制在[0, width]和[0, height]之间二选一。我在实际项目里最深的体会是透明线条这个看起来很小的视觉需求真正复杂的部分从来不是画出来而是画得稳。同一段代码在鼠标上跑得好好的换到触控笔、换到高分屏、换到页面有滚动容器总有一个组合会出问题。所以每加一个特性我现在的习惯是至少在三套环境下过一遍——普通鼠标的桌面浏览器、开了缩放的桌面浏览器、触屏设备——问题基本都能在十分钟内暴露出来比上线之后再排查省事得多。