1. 项目缘起与整体设计思路1.1 为什么会有 artcraft 这个想法做创意工具这些年我最大的感受是大部分所谓的“创作平台”其实是在替用户做决定。你打开一个在线设计工具它给你一堆模板你只能改改文字、换换颜色你打开一个绘画应用它给你一堆笔刷但笔触的响应逻辑是写死的。用久了你会发现你产出的东西带着强烈的“平台味道”——一眼就能看出来是用哪个工具做的。artcraft 这个项目最初就是冲着这个问题去的。它的核心定位是一个面向个人创作者的轻量级创意工坊框架不是又一个在线编辑器而是一套可以自己掌控渲染管线、自己定义工具行为、自己决定交互逻辑的底层结构。说得再直白一点它给你的是画笔和颜料的生产配方而不是一盒已经调好色的颜料。这个项目适合谁如果你是一个前端开发者想做一个有自己风格的绘图或设计工具artcraft 可以给你一套干净的架构参考如果你是一个创意工作者对现有工具的交互方式不满意想理解一个创作工具到底是怎么运转的artcraft 的设计思路能帮你建立完整的认知如果你是一个刚入门的技术爱好者想找一个不太复杂但足够完整的项目来练手artcraft 的模块划分和实现方式也足够友好。我之所以强调“框架”而不是“应用”是因为 artcraft 在设计之初就做了一个关键取舍不做大而全的功能堆砌而是把核心的渲染循环、工具状态管理、输入事件抽象这三件事做扎实。剩下的具体功能比如画笔、橡皮、图层、滤镜都是在这套骨架之上生长出来的。这个取舍背后的逻辑很简单——功能是永远做不完的但骨架一旦歪了后面加什么功能都别扭。1.2 核心架构的选型考量artcraft 的整体架构可以概括为“一个循环、两层状态、三条管线”。“一个循环”指的是渲染循环。不管你是画一笔、拖一个图形、还是应用一个滤镜最终都要落到画布的重新绘制上。artcraft 没有采用“每次操作直接操作 DOM”的方式而是维护了一个统一的渲染循环所有视觉变化都通过状态变更触发重绘。这样做的好处是渲染逻辑和业务逻辑彻底解耦你可以在任何时候暂停渲染、回放渲染、甚至把渲染结果导出成序列帧。“两层状态”指的是工具状态和文档状态。工具状态描述的是“当前用户在用什么工具、这个工具的参数是什么”比如画笔的粗细、颜色、透明度文档状态描述的是“画布上有什么”比如图层的结构、每个图层上的笔触数据、图形的几何信息。这两层状态分开管理好处是切换工具不会影响文档内容而文档的变更也不会污染工具配置。我见过不少项目把这两者混在一起结果就是撤销操作变得极其复杂——你撤销一步可能把工具参数也撤回去了。“三条管线”指的是输入管线、处理管线、输出管线。输入管线负责把鼠标、触控笔、键盘的事件统一成内部事件格式处理管线负责把输入事件转换成具体的操作指令比如“从 A 点到 B 点画一条线”输出管线负责把操作结果渲染到画布上或者导出成图片、SVG 等格式。这三条管线各司其职任何一条管线的改动都不会波及其他两条。这里有一个很关键的工程经验很多绘图工具在早期为了快速出效果会把输入事件直接绑到渲染函数上结果就是一旦要支持触控笔的压力感应或者手势操作整个事件处理逻辑就要推倒重来。artcraft 从一开始就把输入抽象层独立出来虽然前期多写了一些代码但后面接入不同输入设备时几乎没有改动核心逻辑。1.3 技术栈的选择与理由artcraft 的技术栈选择遵循一个原则能用浏览器原生能力解决的不引入额外依赖。渲染层用的是 Canvas 2D API。有人可能会问为什么不用 WebGL答案很简单artcraft 的目标场景是二维创意工具Canvas 2D 在二维图形绘制上的开发效率和调试便利性远超 WebGL。WebGL 的优势在于三维渲染和大规模并行计算但对于一个以笔触、图形、图层为核心的创作工具来说Canvas 2D 的性能完全够用而且代码可读性高得多。当然如果后续要加入实时滤镜或者复杂混合模式可以局部引入 WebGL 做加速但核心渲染管线保持不变。状态管理没有用任何第三方库而是自己实现了一个极简的发布订阅模型。原因在于创作工具的状态变更频率极高——鼠标移动的每一帧都可能触发状态更新——如果用一个通用的状态管理库性能开销和调试复杂度都会上升。自己实现的发布订阅模型只有不到两百行代码但完全贴合 artcraft 的需求支持细粒度订阅、支持批量更新、支持状态快照。构建工具用的是 Vite。这个选择没什么好纠结的Vite 的冷启动速度和热更新体验在目前的工具链里是第一梯队的而且配置简单不需要为了构建一个创意工具去折腾复杂的打包配置。2. 核心细节解析与实操要点2.1 渲染循环的设计与实现细节渲染循环是 artcraft 的心脏。它的基本逻辑是维护一个脏标记当状态变更时把脏标记置为 true在每一帧的末尾检查脏标记如果为 true 就执行重绘。这个设计的关键在于“帧的末尾”这个时机。浏览器提供的requestAnimationFrame会在每一帧的绘制前调用回调函数artcraft 把渲染逻辑放在这个回调里确保渲染和浏览器的刷新节奏同步。如果你在状态变更时直接调用渲染函数一次鼠标移动可能触发几十次重绘性能直接崩掉。而用脏标记加帧同步的方式无论一帧内状态变更多少次最终只重绘一次。具体实现上artcraft 的渲染循环大致是这样的let isDirty false; let rafId null; function markDirty() { isDirty true; if (!rafId) { rafId requestAnimationFrame(renderFrame); } } function renderFrame() { rafId null; if (!isDirty) return; isDirty false; // 清空画布 ctx.clearRect(0, 0, canvas.width, canvas.height); // 按图层顺序绘制 for (const layer of docState.layers) { if (!layer.visible) continue; drawLayer(ctx, layer); } // 绘制工具预览比如画笔的笔触预览 if (toolState.preview) { drawPreview(ctx, toolState.preview); } }这段代码看起来简单但有几个细节值得展开说。第一个细节是清空画布的方式。clearRect是最直接的方式但如果你的画布有背景色或者背景图就需要先绘制背景再绘制图层。artcraft 的做法是把背景也当作一个特殊的图层来处理这样渲染逻辑就统一了。第二个细节是图层绘制的顺序。图层的顺序决定了遮挡关系artcraft 用数组的索引来表示图层顺序索引越大越靠前。每次绘制时从索引 0 开始遍历保证底层的图层先画。这个逻辑听起来理所当然但在实际实现中很容易搞反——我见过不少项目因为图层顺序搞反导致橡皮擦擦不掉东西因为橡皮擦的图层被画在了最底下。第三个细节是工具预览的绘制时机。工具预览指的是用户在画布上移动但还没有确认操作时的视觉反馈比如画笔的笔触轨迹、图形的拖拽框。这部分内容不应该被记录到文档状态里所以它在所有图层绘制完之后单独绘制。这样做的好处是预览的绘制逻辑和文档的绘制逻辑完全分离预览的样式可以随时调整而不影响最终输出。实操心得渲染循环里最容易被忽视的是“不必要的重绘”。比如用户只是移动了鼠标但没有按下任何按钮这时候其实不需要重绘整个画布只需要重绘预览层。artcraft 的做法是把脏标记分成两级fullDirty表示需要全量重绘previewDirty表示只需要重绘预览层。这个优化在图层数量多的时候效果非常明显。2.2 工具状态管理的设计模式工具状态管理是 artcraft 里最体现设计功力的部分。一个创作工具通常有几十种工具每种工具都有自己的参数和行为如果不好好设计代码会迅速膨胀成一团乱麻。artcraft 采用的模式是工具即对象行为即方法。每个工具都是一个独立的对象包含三个核心部分params参数、onPointerDown按下时的行为、onPointerMove移动时的行为、onPointerUp抬起时的行为。当用户切换工具时只是把当前工具对象的引用换掉其他逻辑完全不用改。const brushTool { name: brush, params: { size: 4, color: #000000, opacity: 1.0, hardness: 0.8 }, onPointerDown(ctx, point) { this.currentStroke { points: [point], params: { ...this.params } }; }, onPointerMove(ctx, point) { if (!this.currentStroke) return; this.currentStroke.points.push(point); markDirty(); }, onPointerUp(ctx) { if (!this.currentStroke) return; docState.layers[docState.activeLayer].strokes.push(this.currentStroke); this.currentStroke null; markDirty(); } };这个模式的好处是扩展性极强。你要加一个新工具只需要写一个新的工具对象注册到工具列表里其他什么都不用动。而且每个工具的行为逻辑是自包含的调试的时候可以单独把某个工具拎出来测试不会牵扯到其他工具。但这里有一个容易踩的坑工具参数的共享与隔离。比如画笔和橡皮擦都有“大小”这个参数但它们应该是独立的还是共享的artcraft 的选择是独立。原因很简单用户把画笔调成 10 像素切换到橡皮擦时希望橡皮擦还是上次的大小而不是跟着画笔变。这个细节看起来小但直接影响使用体验。另一个坑是工具状态的持久化。用户刷新页面后工具参数应该恢复默认值还是保留上次的设置artcraft 的做法是把工具参数存到localStorage里刷新后自动恢复。这个功能实现起来很简单但对用户体验的提升很大——没有人愿意每次打开工具都重新调一遍参数。2.3 输入事件的抽象与归一化输入事件的抽象是 artcraft 里最容易被低估的部分。浏览器提供的输入事件至少有三种鼠标事件、触控事件、指针事件。指针事件PointerEvent是目前的标准它统一了鼠标、触控、触控笔的输入但在一些旧设备上兼容性还不够好。artcraft 的策略是优先使用指针事件降级到鼠标和触控事件。归一化的核心是把不同来源的事件统一成内部格式function normalizePointerEvent(e) { const rect canvas.getBoundingClientRect(); return { x: (e.clientX - rect.left) * (canvas.width / rect.width), y: (e.clientY - rect.top) * (canvas.height / rect.height), pressure: e.pressure ! undefined ? e.pressure : 0.5, tiltX: e.tiltX || 0, tiltY: e.tiltY || 0, pointerType: e.pointerType || mouse }; }这段代码里有几个关键点。第一个是坐标转换。画布的 CSS 尺寸和实际像素尺寸可能不一致比如为了适配高分辨率屏幕画布的width和height属性是 CSS 尺寸的两倍所以需要按比例换算。如果不做这个换算笔触的位置会偏移而且偏移量随画布大小变化非常难排查。第二个是压力值的默认处理。鼠标没有压力感应e.pressure在鼠标事件里通常是 0.5 或者 0。artcraft 的做法是如果设备不支持压力感应就统一给一个默认值 0.5这样画笔的压力响应逻辑不需要针对不同设备写分支。第三个是指针类型的保留。虽然 artcraft 目前没有针对不同指针类型做差异化处理但保留这个信息为后续扩展留了口子。比如以后可以针对触控笔做倾斜感应针对鼠标做右键菜单这些都需要知道当前是什么设备。注意事项输入事件的处理函数里不要做任何耗时操作。我见过有项目在pointermove里直接做路径平滑计算结果在低端设备上直接卡死。正确的做法是事件处理函数只负责收集原始数据把计算逻辑放到渲染循环里做。artcraft 的做法是pointermove只把点追加到一个缓冲区渲染循环里再对缓冲区做平滑和简化。3. 实操过程与核心环节实现3.1 从零搭建项目骨架的完整步骤如果你要基于 artcraft 的思路从零搭一个项目下面是我实测下来最顺的步骤。第一步是初始化项目结构。用 Vite 创建一个原生 JavaScript 项目目录结构大致如下artcraft/ ├── index.html ├── src/ │ ├── main.js # 入口文件 │ ├── core/ │ │ ├── renderer.js # 渲染循环 │ │ ├── state.js # 状态管理 │ │ └── input.js # 输入抽象 │ ├── tools/ │ │ ├── brush.js │ │ ├── eraser.js │ │ └── shape.js │ └── utils/ │ ├── math.js │ └── color.js └── package.json这个结构的关键是把core、tools、utils分开。core里的代码不依赖任何具体工具tools里的代码只依赖core提供的接口utils是纯函数工具库。这样的分层保证了核心逻辑的稳定性——你加十个新工具core里的代码一行都不用改。第二步是实现状态管理模块。artcraft 的状态管理模块只有两个核心 APIgetState()和setState()。setState接受一个更新函数这个函数接收当前状态返回新的状态。更新完成后状态管理模块会通知所有订阅者。const listeners new Set(); let state { doc: { layers: [], activeLayer: 0 }, tool: { current: brush, params: {} } }; function getState() { return state; } function setState(updater) { const next updater(state); if (next state) return; state next; listeners.forEach(fn fn(state)); } function subscribe(fn) { listeners.add(fn); return () listeners.delete(fn); }这个实现极其简单但足够用。关键的设计决策是状态不可变——每次更新都返回一个新对象而不是直接修改原对象。这样做的好处是你可以随时保存状态快照实现撤销重做功能时只需要把快照压栈弹栈就行。第三步是实现渲染循环。前面已经讲过渲染循环的核心逻辑这里补充一个实操细节画布的初始化。画布的像素尺寸需要根据设备像素比devicePixelRatio来设置否则在高分辨率屏幕上画出来的线条会模糊。function initCanvas(canvas) { const dpr window.devicePixelRatio || 1; const rect canvas.getBoundingClientRect(); canvas.width rect.width * dpr; canvas.height rect.height * dpr; const ctx canvas.getContext(2d); ctx.scale(dpr, dpr); return ctx; }这段代码里ctx.scale(dpr, dpr)是关键。它让后续所有的绘制操作都按照 CSS 像素来写不用关心设备像素比。如果不做这个缩放你在高分辨率屏幕上画一个 10 像素的圆实际渲染出来只有 5 个物理像素看起来就是模糊的。第四步是实现第一个工具。建议从画笔开始因为画笔的逻辑最直观按下时记录起点移动时追加点抬起时把整条笔触保存到文档状态。画笔的实现难点在于笔触的平滑。如果直接把鼠标移动的点连成线画出来的线条会有明显的折角。artcraft 用的是二次贝塞尔曲线平滑具体做法是取相邻三个点的中点作为控制点这样画出来的线条自然流畅。function drawStroke(ctx, stroke) { const points stroke.points; if (points.length 2) return; ctx.beginPath(); ctx.moveTo(points[0].x, points[0].y); for (let i 1; i points.length - 1; i) { const midX (points[i].x points[i 1].x) / 2; const midY (points[i].y points[i 1].y) / 2; ctx.quadraticCurveTo(points[i].x, points[i].y, midX, midY); } ctx.lineTo(points[points.length - 1].x, points[points.length - 1].y); ctx.stroke(); }实操心得笔触平滑的参数需要根据实际使用场景调整。如果平滑过度笔触会显得“肉”失去手绘的锐利感如果平滑不足线条会有锯齿。我的经验是对于普通画笔取相邻三个点做平滑就够了对于需要精细控制的场景比如签名可以关闭平滑直接用直线连接。3.2 图层系统的实现与性能优化图层是 artcraft 里最影响性能的模块。一个文档可能有几十个图层每个图层上有几百条笔触如果每次重绘都从头遍历所有笔触性能会随着创作过程越来越差。artcraft 的优化策略是分层缓存。每个图层维护一个离屏画布OffscreenCanvas或者普通的canvas元素当图层内容变更时只重绘这个图层的离屏画布然后把离屏画布的内容合成到主画布上。这样重绘主画布时只需要做图层合成不需要重新绘制每条笔触。class Layer { constructor(width, height) { this.canvas document.createElement(canvas); this.canvas.width width; this.canvas.height height; this.ctx this.canvas.getContext(2d); this.strokes []; this.dirty true; } addStroke(stroke) { this.strokes.push(stroke); this.dirty true; } render() { if (!this.dirty) return; this.ctx.clearRect(0, 0, this.canvas.width, this.canvas.height); for (const stroke of this.strokes) { drawStroke(this.ctx, stroke); } this.dirty false; } }这个设计的核心是脏标记的粒度。每个图层有自己的脏标记只有内容变更的图层才需要重绘。在实际使用中用户通常只在一个图层上操作所以每次重绘只需要更新一个图层的离屏画布其他图层直接复用缓存。但这里有一个内存问题每个图层都维护一个全尺寸的离屏画布如果图层数量多内存占用会很大。artcraft 的做法是按需分配——只有当图层上第一次有内容时才创建离屏画布。对于空图层不分配任何内存。另一个优化点是笔触的简化。用户在画一条线时鼠标移动事件可能产生几百个点但其中很多点是冗余的——它们几乎在一条直线上。artcraft 在保存笔触之前会做一次道格拉斯-普克简化把冗余的点去掉。这个简化在笔触保存时做一次后续渲染时就不用再处理了。function simplifyPoints(points, tolerance 1.0) { if (points.length 2) return points; let maxDist 0; let maxIndex 0; const first points[0]; const last points[points.length - 1]; for (let i 1; i points.length - 1; i) { const dist perpendicularDistance(points[i], first, last); if (dist maxDist) { maxDist dist; maxIndex i; } } if (maxDist tolerance) { const left simplifyPoints(points.slice(0, maxIndex 1), tolerance); const right simplifyPoints(points.slice(maxIndex), tolerance); return left.slice(0, -1).concat(right); } return [first, last]; }这个简化算法的时间复杂度是 O(n log n)对于几百个点的笔触来说耗时在毫秒级别完全不影响体验。但简化后的笔触数据量可能只有原来的十分之一对于图层数量多、笔触密集的文档来说渲染性能提升非常明显。3.3 撤销重做功能的实现方案撤销重做是创作工具的标配功能但实现起来有很多种方案每种方案都有各自的取舍。artcraft 采用的是命令模式加状态快照的混合方案。具体来说每个操作画一笔、删除一个图层、修改工具参数都被封装成一个命令对象命令对象包含do和undo两个方法。执行操作时把命令对象压入撤销栈撤销时从撤销栈弹出命令并执行undo方法。class DrawStrokeCommand { constructor(layerId, stroke) { this.layerId layerId; this.stroke stroke; } do(state) { const layer state.doc.layers[this.layerId]; layer.strokes.push(this.stroke); layer.dirty true; } undo(state) { const layer state.doc.layers[this.layerId]; layer.strokes.pop(); layer.dirty true; } }这个方案的好处是内存占用小——每个命令只存储必要的数据不需要保存整个文档的快照。但它的缺点是对于某些操作undo方法很难实现。比如“合并图层”这个操作合并后原始图层的数据就丢失了撤销时需要恢复这些数据。artcraft 的做法是对于这类操作在命令对象里保存必要的数据快照相当于局部快照。注意事项撤销栈的深度需要限制。如果不限制用户连续操作几百次后内存会被撤销栈占满。artcraft 默认限制撤销栈深度为 50超过后自动丢弃最早的命令。这个值可以根据实际需求调整但一般不建议超过 100。另一个实操细节是撤销重做与渲染循环的配合。撤销操作会修改文档状态需要触发重绘。artcraft 的做法是命令执行完毕后统一调用markDirty()而不是在命令内部各自触发。这样做的好处是如果一次用户操作产生了多个命令比如批量删除图层只需要触发一次重绘。4. 常见问题与排查技巧实录4.1 笔触偏移与坐标换算问题笔触偏移是绘图工具里最常见的问题表现是画笔的位置和鼠标指针的位置对不上而且偏移量随画布位置变化。这个问题的根源通常是坐标换算没有考虑画布的偏移和缩放。浏览器提供的clientX和clientY是相对于视口的坐标需要减去画布的getBoundingClientRect()的left和top才能得到相对于画布的坐标。如果画布有 CSS 缩放比如transform: scale(0.8)还需要除以缩放比例。function getCanvasPoint(e, canvas) { const rect canvas.getBoundingClientRect(); const scaleX canvas.width / rect.width; const scaleY canvas.height / rect.height; return { x: (e.clientX - rect.left) * scaleX, y: (e.clientY - rect.top) * scaleY }; }排查这个问题的技巧是在画布上画一个十字线然后在四个角分别点击看笔触是否落在十字线的交点上。如果四个角的偏移量不一致说明是缩放问题如果偏移量一致说明是偏移问题。4.2 渲染性能突然下降的排查思路渲染性能下降通常有几个原因按出现频率排序图层数量过多、笔触数据量过大、渲染循环里做了不必要的计算、内存泄漏导致垃圾回收频繁。排查的第一步是确认问题出现的时机。是打开文档就卡还是画到一定数量后开始卡如果是打开就卡说明是文档数据量的问题如果是画到一定数量后开始卡说明是累积效应。第二步是用性能面板定位瓶颈。浏览器的开发者工具里有性能面板录制一段操作后可以看到每一帧的耗时分布。如果大部分时间花在drawStroke上说明笔触渲染是瓶颈如果花在clearRect上说明画布尺寸太大。第三步是针对性优化。对于笔触渲染瓶颈可以启用图层缓存对于画布尺寸问题可以降低画布分辨率或者分块渲染对于内存泄漏可以用内存面板检查是否有未释放的离屏画布或事件监听器。实操心得我遇到过一次性能问题排查了很久才发现是pointermove事件里调用了getBoundingClientRect()。这个 API 会触发浏览器的重排在pointermove里高频调用会导致严重的性能问题。解决办法是在画布尺寸变化时缓存getBoundingClientRect()的结果pointermove里直接用缓存值。4.3 常见问题速查表问题现象可能原因排查方法解决方案笔触位置偏移坐标换算未考虑画布偏移或缩放在画布四角点击观察偏移量是否一致使用getBoundingClientRect做坐标换算线条锯齿明显未做笔触平滑或设备像素比未处理放大画布观察线条边缘启用二次贝塞尔平滑设置devicePixelRatio撤销后画面未更新撤销命令未触发重绘检查命令执行后是否调用markDirty在命令执行完毕后统一触发重绘图层顺序错乱图层数组索引与绘制顺序不一致检查绘制循环的遍历方向确保索引 0 的图层最先绘制高分辨率屏幕模糊画布像素尺寸未按设备像素比设置对比 CSS 尺寸和画布width属性设置canvas.width rect.width * dpr长时间使用后卡顿撤销栈或笔触数据累积过多检查内存占用和撤销栈深度限制撤销栈深度简化笔触数据触控笔压力无响应未处理pressure属性或设备不支持打印e.pressure观察数值为不支持压力的设备设置默认值4.4 几个容易被忽视的细节问题第一个细节是画布尺寸变化时的处理。当浏览器窗口大小变化时画布的 CSS 尺寸会变但画布的像素尺寸不会自动更新。如果不处理画布内容会被拉伸变形。artcraft 的做法是监听resize事件重新设置画布的像素尺寸并重新绘制所有图层。第二个细节是触摸设备的默认行为。在触摸设备上手指在画布上滑动会触发页面的滚动和缩放。如果不阻止默认行为用户画一笔就会把页面滚走。解决办法是在画布上监听touchstart和touchmove事件调用preventDefault()。第三个细节是右键菜单的屏蔽。在绘图工具里右键通常用于呼出工具菜单或者作为橡皮擦的快捷方式。如果不屏蔽浏览器的默认右键菜单用户体验会很割裂。artcraft 的做法是监听contextmenu事件并调用preventDefault()然后自己实现右键菜单。第四个细节是键盘快捷键的冲突。创作工具通常有大量快捷键比如CtrlZ撤销、CtrlS保存、B切换画笔。这些快捷键需要和浏览器的默认快捷键协调比如CtrlS会触发浏览器的保存页面功能需要阻止默认行为。artcraft 的做法是维护一个快捷键映射表在keydown事件里统一处理。5. 扩展方向与个人经验分享5.1 可以继续深挖的几个方向artcraft 目前的实现是一个最小可用的骨架但它的架构留了很多扩展口子。第一个扩展方向是协作编辑。artcraft 的状态管理模块采用的是发布订阅模式这个模式天然适合接入实时协作。你只需要把状态变更通过 WebSocket 广播出去其他客户端收到后应用到本地状态即可。当然真正的协作编辑还需要处理冲突解决、操作变换等问题但架构层面不需要大改。第二个扩展方向是插件系统。artcraft 的工具对象是自包含的这意味着你可以把工具的定义放到单独的模块里运行时动态加载。用户可以根据自己的需求安装不同的工具包比如“水彩笔工具包”、“几何图形工具包”、“文字排版工具包”。这个扩展方向的关键是定义好工具对象的接口规范确保第三方工具能无缝接入。第三个扩展方向是导出与打印。artcraft 的文档状态是结构化的数据导出成 SVG 或者 PDF 都很直接。SVG 导出只需要把笔触数据转换成path元素PDF 导出可以借助现有的库把 SVG 转换成 PDF。这个方向对于有打印需求的用户来说很有价值。5.2 我在实际开发中踩过的坑第一个坑是过早优化。项目初期我花了很多时间在渲染性能优化上结果后来发现大部分用户的使用场景根本不会触及性能瓶颈。如果重来一次我会先把功能做完整等到真正出现性能问题时再针对性优化。第二个坑是状态管理的粒度。一开始我把所有状态放在一个大对象里任何变更都触发全量重绘。后来发现这样不行因为工具参数的变更比如调整画笔大小不应该触发文档重绘。把状态拆成工具状态和文档状态之后这个问题就解决了。第三个坑是输入事件的兼容性。我一开始只用了指针事件结果在一些旧设备上完全无法使用。后来加了鼠标和触控事件的降级处理兼容性问题才解决。这个教训是不要假设用户的设备支持最新的 API。第四个坑是撤销重做的边界情况。我一开始只考虑了正常的操作序列后来发现用户可能会在撤销后执行新操作这时候重做栈需要清空。还有如果撤销栈为空时用户继续撤销应该什么都不做而不是报错。这些边界情况在测试时很容易遗漏但用户在实际使用中一定会遇到。5.3 给想上手这个项目的朋友几点建议如果你打算基于 artcraft 的思路做一个自己的创作工具我的建议是先跑通最小闭环再逐步扩展。最小闭环就是“画一笔、看到笔触、能撤销”。这个闭环跑通之后你就有了一个可用的工具后续的图层、滤镜、导出都是在这个基础上生长出来的。另外不要一开始就追求功能的完整性。我见过很多项目功能列表列了几十项结果每一项都做得半吊子。artcraft 的选择是把画笔和橡皮擦做到极致其他工具慢慢加。这个策略的好处是用户至少有一个理由用你的工具——画笔的手感好。最后多花时间在交互细节上。创作工具的核心竞争力不是功能多少而是用起来顺不顺手。笔触的平滑度、撤销的响应速度、快捷键的合理性这些细节决定了用户会不会持续使用你的工具。功能可以慢慢加但交互体验一旦差了用户可能再也不会回来。