做这个项目的直接导火索其实特别普通：我在写一个在线简历生成器，用户需要上传头像，然后用一个圆角矩形或者圆形把头像“裁”出来。最开始我直接套了个 CSS 的 border-radius，但需求一变就麻烦——用户要星形、多边形、甚至用另一张图裁头图。于是我把这个功能抽了出来，一路做到了“画布上随便画两个形状，一个能把另一个直接剪掉”的程度。整个工具没有引入任何第三方库，纯原生 Canvas + JavaScript，代码量最终停在 6200 行左右。今天这篇就把形切形功能的底层逻辑、实现细节和踩过的坑完整拆开讲一讲。
这个项目解决的核心问题分两层：第一，图片/图形如何按任意形状边界输出（也就是遮罩裁剪）；第二，两个形状做布尔差集运算，把重叠部分从图形上“扣掉”，生成新的可编辑路径。如果你正准备做在线设计工具、图片编辑器、可视化搭建平台里的图形裁剪能力，或者想看看不依赖任何图形库时原生 Canvas 的上限在哪，这篇文章会比较适合你。6200 行不算多，但里面每条路径、每个变换、每个重绘决策，都是我在长期维护中反复调整过的。
1. 项目定位与整体设计：6200 行代码到底做了什么
1.1 “形切形”到底是什么：两种核心场景
在网页设计工具里，“形切形”其实是一个俗称，落到具体实现上，它包含了两类非常常见的需求。
第一类是遮罩式裁剪。典型场景就是用户上传一张图片，工具把它塞进一个自定义形状里，输出时图片只在形状内部可见，形状外部全部透明。头像裁剪、商品图抠底、海报贴纸都属于这种。实现上只需要利用 Canvas 的 clip 方法，先描出形状路径，再把图片绘制进去，Canvas 会自动把路径外部的绘制裁掉。
第二类是布尔差集。画布上有形状 A 和形状 B，选中它们执行“切掉”操作，结果是形状 A 中与 B 重叠的部分消失，剩下的是一个带“缺口”的新形状。这个新形状仍然是一条可编辑路径，能继续改颜色、做阴影、放大缩小，甚至参与下一次裁剪。这个才是形切形里技术难度比较高的部分，也是我花了最长时间调试的地方。
我在工具里两种都做了。用户选中某个图形作为“刀子”，可以把它盖到目标图形上完成遮罩裁剪；如果同时选中两个独立形状，则走布尔差集流程。两者在交互入口上分得比较清楚，但底层其实共用了一套核心数据结构，没有为每种形态单独写死逻辑，这样后续扩展“并集”“交集”这些运算模式也会很方便。
1.2 零依赖的底气：原生 Canvas 能做多少事
决定不引库，一是为了控制最终产物体积，二是我确实想看看规范里的 Canvas 能力到底够不够撑起一个轻量图形编辑器。
先说结论：原生 Canvas 搞定形切形是够的，但你需要把几个 API 吃透，而不是停留在“会画一个方块”的层面。
Path2D：可以把一段复杂路径保存为对象，反复绘制、作为裁剪区域、参与点击检测，性能比每次重新拼路径字符串好很多。ctx.clip(path)：以某条路径为边界限制后续所有绘制，这是遮罩式裁剪的核心入口。ctx.isPointInPath()：判断一个点是否落在某条路径内部。注意，它有路径参数和坐标参数，但在画布发生 transform 变换时容易踩坑，后面会专门讲。globalCompositeOperation：可以快速实现 destination-in、destination-out 这类像素级合成效果，很多人第一个想到的就是用它做裁剪。但它有一个致命问题：结果是位图，一旦合成，路径信息就没有了。
所以真正的设计决策在于：哪些能力负责“显示”，哪些能力负责“数据”。我的做法是，显示层用 clip 和 Path2D，数据层维护一套轻量级几何对象，所有形切操作都在几何数据上执行，最后再交给 Canvas 渲染。这样既保留矢量可编辑性，又不牺牲原生 API 带来的性能优势。
Fabric.js 和 Konva.js 确实是成熟方案，但它们的体积和抽象层决定了你不是在“写工具”，而是在“配置配置项”。对于想彻底掌握底层原理、或者交付体积有严格要求的场景，原生方案值得认真考虑。
1.3 6200 行代码的构成
6200 行听起来好像很多，但拆开之后每块其实都不复杂。我的项目大致分布是这样的：
- 事件系统与画布核心：约 700 行，负责坐标系换算、渲染循环、对象管理。
- 图形建模（矩形、圆形、多边形、路径模板）：约 1100 行，每种图形一个类。
- 形切形核心：约 1400 行，包含折线化、线段求交、差集运算、路径重建。
- 渲染器：约 700 行，负责绘制每个形状、选中框和控制点。
- 交互层：约 1100 行，拖拽、缩放手柄、键盘事件、模式切换。
- 导出与工具函数：约 700 行，PNG 导出、SVG path 序列化、颜色解析等。
- 基础 UI（工具栏、属性面板入口）：约 500 行。
这个划分的优点是职责清晰，形切形运算模块不依赖 DOM 和 Canvas 实例，纯 JavaScript 对象进出，方便单测和复用。你要自己写类似工具的话，建议也保持这个边界，特别是几何算法部分一定要和渲染解耦，否则后面调试布尔运算的时候会被 canvas 状态搞得完全没法定位问题。
2. 形切形的底层逻辑与算法选择
2.1 先分清“遮罩式裁剪”和“布尔差集”
很多初学 Canvas 的人会把形切形直接等同于ctx.clip()，但这是理解上的一个偏差。clip 是一个 GPU/渲染层行为，它影响的是“接下来画的内容显示在哪里”，而并没有改变图形本身的几何数据。换句话说，你让 Canvas 帮你把图片裁剪成星形，Canvas 不会生成一个“星形图片对象”，它只是在输出时把该隐藏的部分隐藏了。
布尔差集则完全不同。它要做的是真正的几何计算：找出形状 A 与形状 B 的轮廓交点，重新拼接出一段不包含 B 内部区域的闭合路径。这个结果是数据层面上的新路径，可以被存储、重新渲染、再次编辑。
我做产品时对这两种方式的取舍是：所有需要后续编辑能力的功能，必须走几何计算；只有最终导出图片这种“一锤子买卖”，才用 clip 配合离屏画布去渲染。举个例子，用户用星形裁了一张头图，如果头图还能拖来拖去调整位置，那么我不能把像素直接“烧”进去，否则每次拖动都得重新裁一遍。正确做法是保存“头图 + 星形路径”的引用关系，渲染时临时用 clip 限定显示区域，拖动的只是图片的位置属性。
而布尔差集的场景里，用户选中矩形和圆形执行“切掉”，这个操作完成后，矩形和圆形的独立性就消失了，取而代之的是一个新形状。我必须马上计算出这个新形状的路径数据，后续的拖拽和变换全部作用在这个新对象上。这两个流程一个偏渲染，一个偏计算，是形切形项目里最核心的架构分叉点。
2.2 我的方案：Path2D + clip 做输出，折线近似做预览
真正的曲线布尔运算是图形学里公认难啃的骨头，尤其要处理贝塞尔曲线之间的求交、切向连续性、退化情况。在零依赖约束下，我没必要在第一个版本就撞这道墙。
我的做法是：对曲线做“可控折线化”，也就是把每条贝塞尔曲线拆成若干条首尾相连的直线段，然后用多边形差集的算法去处理。折线化的精度由一个参数控制，用户执行裁剪时需要满足一定的像素误差阈值，默认情况下每段曲线的拟合误差控制在 0.5px 以内，肉眼基本看不出是折线。
折线化之后，问题就简化成了“两个多边形如何做差集”。大致步骤是：
- 遍历多边形 A 的每条边，和二多边形 B 的每条边求线段交点。
- 把所有交点按参数值插入到各自的顶点序列里。
- 从一个交点出发，沿着 A 的轮廓前进，如果当前线段进入了 B 的内部，就在交点处切换到 B 的轮廓反向，继续绕行，直到回到起点。
- 收集整个绕行过程经过的顶点，组成差集结果的外环。
这是经典的“Weiler–Atherton 裁剪算法”的简化版。它不要求两个多边形是凸多边形，只要轮廓是简单多边形（不自交）就可以工作。我这个工具的 1.0 版本只支持简单多边形，遇到自交路径会直接提示用户先简化路径。
这个方案的直接结果是：用户在编辑时看到的是近似差集的预览，但误差非常小。而在最终导出时，我会把这个近似路径转回 Path2D，用离屏 Canvas 配合 clip 去渲染高清图。由于导出图片的尺寸可以放大，折线误差会同步放大，所以导出时我会动态提高折线化的分段密度。打个比方：编辑时我拿一个十段的圆去参与路径计算，导出时可能用两百段，这样既保证编辑流畅，又保证导出边缘平滑。
2.3 关键代码：形切形的核心实现
先看一个最基础的遮罩裁剪片段。这里用document.createElement('canvas')创建离屏画布，先绘制内容再绘制蒙版，使用globalCompositeOperation = 'destination-in'时，蒙版会作用在已经绘制的内容上，相当于把内容裁剪进蒙版形状内。
function clipImageToShape(sourceCanvas, shapePath, outputSize) { const out = document.createElement('canvas'); out.width = outputSize.width; out.height = outputSize.height; const ctx = out.getContext('2d'); // 白底蒙版：填充形状路径 ctx.save(); ctx.fillStyle = '#fff'; ctx.fill(shapePath); ctx.restore(); // 仅保留与蒙版重叠的像素 ctx.globalCompositeOperation = 'destination-in'; ctx.drawImage(sourceCanvas, 0, 0, outputSize.width, outputSize.height); return out; }这段代码能处理 90% 的图片遮罩需求，性能也很好。但有一个限制：蒙版是单一路径。如果用户想用多个形状叠加出一个复杂的裁剪区域，需要先把多个路径合并成一条复合路径，再交给 fill，或者用非零环绕规则配合 Path2D.addPath 去处理。我会在工具里通过“组合模式”让用户把多个基础形状编组，然后对这个组生成一个合成后的 Path2D，再执行裁剪。
布尔差集的核心运算函数则长这样，输入两个普通多边形对象，输出一个新多边形对象：
function booleanSubtract(polyA, polyB) { // 1. 先快速筛选包围盒不相交的情况 if (!boundsIntersect(polyA, polyB)) { return clonePolygon(polyA); } // 2. 求两个多边形所有边之间的交点，并按参数值插入顶点序列 const { aWithHits, bWithHits } = computeIntersections(polyA, polyB); // 3. 从 A 的某个交点出发，绕行构建外环 const result = walkBoundary(aWithHits, bWithHits); // 4. 清理退化边（距离过近的点合并） return simplifyPolygon(result, 0.01); }walkBoundary是整个算法里最容易写错的部分。它需要维护“当前点在哪个多边形上、方向朝哪、下一个交点是谁”三个状态，稍一不慎就会陷入死循环。我的调试经验是多打印绕行轨迹，把每个顶点和交点都标到画布上，用可视化方式单步检查，比对着日志空想要高效得多。
性能上，最坏情况是 O(m * n)，也就是两个多边形各自有 m、n 条边，所有边两两求交。设计工具里单个形状的边数一般不会超过几百，这个复杂度完全在可接受范围内。但如果用户画了特别复杂的路径，比如把一张位图自动转换成路径，那就要提前做折线化简，把顶点数压到几千以内，否则交互帧率会有肉眼可见的下降。
3. 实操过程：从空白画布到可交互编辑工具
3.1 画布重绘架构：脏标记是编辑器的第一块基石
Canvas 不像 DOM 那样有增量更新的概念，任何状态变化最终都体现为“重新画一遍”。但“重新画一遍”也要分策略：是每帧清空整个画布然后全量重绘，还是只重绘变化的区域？我做的是增量式脏标记。
整个画布分三层：底层是网格背景，中间是所有业务形状，顶层是选中框和控制点。业务形状本身维护一个dirty标记，只有插入、删除、变换、形切这类操作才会把它置为脏。渲染器在 requestAnimationFrame 回调里检查脏集合，先清空画布，但只重绘脏形状所在包围盒区域，而不是全画布。这里需要额外注意：如果你只用clearRect清掉局部区域，再重画该区域内的形状，会导致该区域下方的内容消失。我的解决办法是给每个形状记录一个“影响区域”，把同一片区域影响到的所有形状都拉到重绘列表里，避免出现残影。
回到全量重绘的老方案，你会发现 6200 行的项目里最简单粗暴但最稳定的反而是全量重绘。后来我保留脏标记机制，主要不是为了省那几毫秒，而是为了让每个形状能够独立触发“局部重绘”这个逻辑，为后面做动画、做实时预览打基础。实际渲染开销里，启动一次 Canvas 重绘比真正绘制所有形状的开销小很多，瓶颈通常在路径填充和阴影计算上。为了优化这一点，我显式关闭了高开销的阴影效果，阴影用离屏画布离线缓存。
3.2 图形数据结构与拾取逻辑
形切形工具里，每个图形都是一个对象，统一结构大致如下：
class Shape { constructor(type, attrs) { this.id = uuid(); this.type = type; // 'rect' | 'circle' | 'polygon' | 'path' this.attrs = attrs; // 不同图形有不同属性 this.x = 0; this.y = 0; this.rotation = 0; this.scaleX = 1; this.scaleY = 1; this.fill = '#2f6fed'; this.stroke = 'transparent'; this.dirty = true; this.zIndex = 0; this.isClipper = false; // 标记是否是裁剪用的“刀子” } }这里需要说明一个细节：attrs 里存的不是屏幕像素坐标，而是图形自身的局部坐标。比如一个矩形存的是{ width: 100, height: 60 }，它的位置由 x、y、rotation、scale 组成的变换矩阵决定。这样形切运算时，输入的路径永远都是基于局部坐标系的，做完运算后结果再跟宿主变换相乘，可以避免在做布尔运算时因为旋转缩放导致的计算误差。
拾取逻辑则利用 Canvas 原生能力，从顶层往下检查：把每个形状的 Path2D 转换到屏幕坐标系，然后调用ctx.isPointInPath(path, mouseX, mouseY)。因为 Canvas 已经帮我做了路径包含判断，我只需要处理层级的倒序遍历，从最上层往下找，第一个命中的就是用户点中的对象。这里唯一的坑是点击选中的判定带有 1px 误差，容易在图形边缘恰好点不中。我加了一个容错：先用 3px 半径的扩展范围做一次粗拾取，粗拾取不中再判断是否命中控制点，最后才判定为点击空画布。
3.3 交互细节：拖拽、控制点与形切执行流程
拖拽相对简单：mousedown 时记录起点和对象原始坐标，mousemove 时计算 dx/dy，用 shift 键约束为水平或垂直移动。但一旦形切后生成的新形状，它的路径顶点才是关键，我对形切结果做了归一化：不管原图形怎么旋转、缩放，运算完成后都会把结果转换成 1:1 的路径坐标，再重新设置 x/y/rotation/scale。这一步可以保证后续缩放和变换手柄永远面对一个“干净”的几何数据。
形切的完整交互流程是：
- 用户画两个形状 A、B，并用鼠标框选同时选中它们。
- 工具栏里点“形切”按钮，弹出悬浮菜单，选择“A 减去 B”或“B 减去 A”。
- 工具先判断两个形状是否真的相交，不相交直接提示“未检测到重叠区域”。
- 确定运算方向后，进入布尔差集函数，生成新路径，替换掉原来的 A 或 B，并自动取消另一个的选中。
- 新生成的对象颜色继承自目标对象，默认加一个虚线外框表示“这是运算结果”。
这里有一个小交互技巧很值得注意：在执行运算之前，我会在画布中央直接渲染一次“预览结果”，并带一个半透明的原图形虚线轮廓，用户确认无误之后再点击确认执行。因为布尔运算有时候会出现一些微妙的结果差异（比如重叠边界比较接近时，差集结果可能留下一条极细的边），提前预览能避免很多误操作。
3.4 导出：把裁剪结果输出为 PNG/SVG
网页设计工具的最终交付大概率是导出文件。PNG 导出用canvas.toDataURL('image/png')，这没什么好说的，关键是要按导出倍率生成离屏画布。我提供了一个exportScale参数，默认导出 2 倍图，保证在 Retina 屏上依然清晰。处理步骤是在离屏画布上先scale(scale, scale)，再重放一遍绘制逻辑，最后导出。
SVG 导出在零依赖前提下则需要自己拼字符串。Canvas 本身不提供 path 转 SVG 的能力，所以我维护了一个pathToSVGPath的工具函数，把 Path2D 的每个命令逐个转换成 SVG path d 属性的语法。对于布尔差集后的新形状，这个序列化是现成可用的；对于图片遮罩的场景，我会输出一个<clipPath>包裹的图片引用。用户把这个 SVG 导入到 Figma 或者 Illustrator 之后，仍然能保持完整的可编辑性。一开始我只做了 PNG 导出，后来被好几个测试用户问到“能不能导出 SVG”，才回头补上了这块。
4. 踩坑记录与性能优化实录
4.1 isPointInPath 的坐标系坑
这个坑我给所有写 Canvas 交互的人都提个醒：isPointInPath的第二个参数、第三个参数是相对于当前变换矩阵的坐标，而不是绝对画布坐标。
举个例子，画布的ctx.transform(2, 0, 0, 2, 100, 100)之后，你画了一个矩形，这个矩阵让画布上所有内容放大两倍并偏移。然后用户在屏幕位置(300, 280)点击，如果你直接把(300, 280)传给isPointInPath，它会被再乘以一次变换矩阵，导致检测结果完全错位。
解决办法是记录当前画布的完整变换矩阵，在检测前用逆矩阵把鼠标屏幕坐标转换成画布逻辑坐标：
function screenToCanvas(ctx, screenX, screenY) { const transform = ctx.getTransform(); const inverse = transform.invertSelf(); const point = new DOMPoint(screenX, screenY).matrixTransform(inverse); return { x: point.x, y: point.y }; }我最初就是没做逆变换，导致工具栏一切换到缩放模式，拾取就失效。这个 bug 花了整整一个晚上排查，一开始还以为是路径闭合问题。最后在画布上临时打印每个图形的 bounding box 和鼠标坐标，才意识到坐标系完全就不在一个空间里。
4.2 毛边与浮点精度：裁剪结果的“锯齿声明”
布尔差集计算完成后，新路径里往往混着大量的浮点数。比如两条线段的交点坐标是(123.40000000001, 67.8999999999)，如果直接拿去做 fill，不同语法环境下可能因为浮点误差导致边缘出现 1px 的毛边。
我做了三件事来规避：
- 交点统一保留两位小数，后续所有计算基于这个舍入值。
- 新路径生成后跑一遍移除共线点算法，连续三个点如果在同一直线上，删掉中间那个。
- 渲染时给结果路径加一个 0.5px 的描边，颜色取填充色本身，这样能有效掩盖亚像素层面上的锯齿感。
这个描边小技巧是学自某些开源绘图软件的，但注意描边宽度不要超过 1px，否则会让边缘看起来发“肉”，反而影响锐利感。
另外，devicePixelRatio也要纳入考量。高分屏下 Canvas 会自动把逻辑像素映射到物理像素，如果你的坐标系统不处理这一点，导出图片时边缘会明显发虚。我的处理方式是画布内部统一用逻辑像素，所有绘制前做一次ctx.scale(dpr, dpr)，导出时再把 dpr 作为缩放系数乘进去。
4.3 重绘性能：频繁拖拽卡顿怎么排查
在完成基础功能后，我遇到了一个性能问题：拖拽一个复杂形状时，帧率明显掉到 40fps 以下。用 Chrome DevTools 的 Performance 面板录制后看到，拖拽过程中的每一帧都在反复执行 path2D 的创建和 fill，即便形状本身根本没变。
优化手段是给重绘加了双层缓存：
- 形状级缓存：普通形状在不变化的情况下，预渲染到一个离屏 canvas，拖拽时直接
drawImage贴上去。 - 形切结果缓存：布尔运算后的新路径因为顶点多、填充复杂，专门缓存一个高清离屏图，只有当缩放比例超过缓存范围时才重新生成。
加了缓存之后，拖拽流畅度恢复到 60fps。代价是内存占用上升了一些，但在现代浏览器里几乎可以忽略。还有一个小细节：不要在每个 mousemove 回调里直接触发重绘，而是用一个requestAnimationFrame的调度函数合并同一帧内的多次变更请求，保证一个帧周期最多重绘一次。这在多个形状同时被框选移动时效果尤其明显。
5. 给想重造轮子的人几点建议
5.1 什么时候值得自己写，什么时候应该用库
做了这个项目后，我对“造轮子”这件事有了更现实的判断。如果需求只是“给图片加个圆角”，用 CSS 就能解决，完全没必要碰 Canvas。如果你的目标是做一个多图层、多变换、自带大量图形编辑能力的设计软件，踏踏实实去用 Fabric.js 可能更划算，因为你省下的是与你核心业务无关的几何框架代码。
但如果你跟我一样，核心卖点恰恰是“裁剪”或“组合形状”这种偏底层的图形运算能力，而且对结果的可编辑性有要求，那我非常建议自己写核心算法模块，至少把布尔差集这部分握在手里。无关框架可以选型，核心算法最好自研，这是我这个项目最大的心得。依赖库能给你加速，但也会给你设天花板。
5.2 最小可用版本先限制范围
我在第一个版本里只允许矩形、圆形、正多边形三种图形参与形切。路径工具和贝塞尔编辑是后面才加的。如果你一上来就支持任意曲线路径的布尔运算，调试周期至少翻三倍。先跑通基本流程，再把图形类型逐个扩展，每个类型新增时只需要实现统一的路径输出接口，不用动核心运算模块。
这个做法还有一个额外收益：早期用户反馈能快速验证“形切形”这个交互是否符合直觉，即使图形种类少，核心价值已经能体验到了。如果一开始就追求大而全，很可能开发几个月后才发现方向不对。
5.3 代码组织的建议：把几何算法和界面彻底分离
我和很多独立开发者的习惯一样，一开始喜欢渲染写到一半里夹算法、算法里夹 DOM 查询，后来重构时痛不欲生。现在我把几何模块设计成完全不依赖浏览器 API 的纯函数包，可以在 Node 里直接跑单元测试。具体来说，就是多边形求交、折线化、差集运算、路径序列化这些函数，只接受普通数组和对象，返回值也是普通对象，不碰 canvas 上下文。
这样写测试时非常爽。我可以直接构造一个矩形和三角形的顶点数组，断言差集结果的顶点个数和坐标范围，连浏览器都不用开。界面上我只保证一件事：UI 操作最终会转成合理的对象调用，业务状态全部保存在一个可序列化的 store 里，方便后续做撤销重做和历史记录。
5.4 这 6200 行后续怎么扩展
当前版本已经能满足“图形互剪 + 图片遮罩 + PNG/SVG 导出”这条完整链路，但这个架构让我觉得还有很大的扩展空间：一是差集之外的并集、交集运算，算法框架基本可以复用；二是 snap 吸附到对象边缘、智能参考线这类辅助能力，可以极大提升编辑器的手感；三是把几何结果导出为 JSON 格式，让用户可以保存一个“可编辑模板”，而不是只能导出图片。
我个人的下一步计划是把路径支持升级到真正的贝塞尔曲线布尔运算，先通过离线预计算把剪辑能力增强，再去尝试和 Web Worker 结合，让大路径的计算不阻塞主线程。这些方向在项目架构里已经留好了接口，顺着当前的数据流往下加新功能就行，不需要推翻重来。
我在实际开发中的一个很深的体会是：形切形不是一个独立的“按钮”，而是一整套围绕路径和渲染的架构能力的集中体现。当你把一个看似简单的小需求不断往深处做时，它会逼你把图形数据模型、渲染流程、交互反馈、导出链路全部梳理清楚。这个过程中踩过的坑、推倒过的方案，比最终那 6200 行代码本身更有价值。如果你正打算做类似工具，欢迎参考我这里的思路，至少能让你的第一版少走不少弯路。
