1. 从“artcraft”这个名字说起它到底想解决什么问题第一次看到“artcraft”这个词我脑子里蹦出来的不是某个具体工具而是一种很朴素的组合感——art 加上 craft艺术加手艺。这两个词放在一起本身就带着一种张力一边是偏感性、偏表达的创作冲动另一边是偏理性、偏流程的工程化落地。很多做内容、做设计、做小工具的人卡住的地方恰恰就在这两者之间——脑子里有画面手上却拼不出一个能跑、能看、能交付的东西。我接触过不少独立开发者和小团队他们做项目的起点往往不是“我要造一个多牛的系统”而是“我想把某个想法快速变成能看的东西”。这个“能看的东西”可能是一个作品集页面、一个交互式的小玩具、一个带视觉风格的数据展示甚至只是一个能自动生成某种图案的脚本。artcraft 这个标题给我的直觉就是冲着这类需求去的它不追求大而全而是想把“艺术表达”和“手工实现”这两件事捏在一起让创作者不用在审美和代码之间反复横跳。关键词和摘要描述虽然留空但从标题本身能反推出几个核心方向。第一它大概率涉及视觉生成或视觉组织因为 art 这个词天然指向图形、色彩、排版、动效这些看得见的东西。第二craft 暗示了可操作性和过程感不是纯理论而是有步骤、有工具、有手感的实践。第三这类项目通常面向的读者是有一定动手意愿但未必是资深工程师的人比如设计师想学点代码、前端想补点审美、内容创作者想搞点自动化的小玩意。所以这篇博文我不打算把它写成一份冷冰冰的 API 文档而是按一个真实做过类似项目的人的视角把 artcraft 可能涉及的技术选型、实现路径、踩坑经验和扩展思路拆开来讲。如果你正好在琢磨怎么把创意变成可运行的东西或者你手里有一个类似“artcraft”定位的小项目想落地下面的内容应该能直接拿去参考。2. 拆解 artcraft 的核心构成视觉、交互与生成逻辑2.1 视觉层为什么“好看”本身就是一个技术问题很多人觉得视觉是设计师的事跟写代码的没关系。但实际做过项目的人都知道一个东西“好不好看”在技术层面是有明确抓手。artcraft 如果涉及视觉输出那它至少要处理三件事布局、色彩和层次。布局不是简单地摆几个 div。以常见的画布类项目为例元素的位置关系决定了视觉动线。我习惯先用一个很笨的办法在纸上画九宫格把主要元素按重要性标进去然后再换算成百分比坐标。这样做的好处是代码里的定位值不是拍脑袋写的而是有视觉依据的。比如一个生成艺术图案的项目中心区域放主体图形四周留白比例控制在 15% 到 20% 之间视觉上会舒服很多。这个比例不是玄学是大量海报和界面设计里反复验证过的经验值。色彩方面artcraft 这类项目最容易踩的坑是“颜色太多”。我见过不少生成类作品每个元素都给了高饱和度颜色结果像打翻了调色盘。比较稳的做法是限定色板主色一个辅助色两个中性色两到三个总共不超过六个。如果你用代码生成颜色可以用 HSL 模式来控制把色相 H 限制在某个区间内饱和度和亮度做小范围浮动。这样出来的颜色既有变化又不会失控。层次感则依赖阴影、透明度和模糊。CSS 里的box-shadow和filter: blur()是性价比最高的两个属性。但要注意阴影不要用纯黑用带一点主色倾向的深色会更自然。比如主色是蓝紫调阴影就用rgba(30, 20, 60, 0.15)这种而不是rgba(0, 0, 0, 0.2)。这个细节很小但做出来的东西质感差别很大。2.2 交互层让“craft”真正被感受到craft 这个词意味着过程感而过程感在数字产品里主要靠交互来传递。artcraft 如果只是一个静态输出那它跟一张图片没区别。真正让它有“手艺”味道的是用户能参与、能调整、能看到变化。常见的交互模式有三种参数调节、实时预览和导出保存。参数调节是最直接的比如滑块控制密度、大小、旋转角度。这里有个经验滑块的范围不要设得太宽。我试过让一个参数从 0 到 1000结果用户根本找不到合适的值。后来改成 0 到 100默认值放在 40 左右使用体验立刻好了很多。默认值的选择也有讲究它应该是“大多数情况下看起来还不错”的那个值而不是中间值。实时预览的关键是防抖。如果每次滑块移动都触发重绘性能会崩。我一般用requestAnimationFrame配合一个简单的节流逻辑保证每帧最多重绘一次。对于计算量大的生成逻辑还会加一个 100 到 200 毫秒的延迟等用户停下来了再算最终结果。这个延迟不能太长否则会觉得卡也不能太短否则等于没防抖。导出保存看起来简单但坑不少。如果画布内容是动态生成的导出时要注意分辨率。屏幕上的 800x600 导出成图片可能只有 72dpi打印或放大就糊了。我的做法是维护一个“导出比例”参数默认 2 倍用户有需要可以调到 4 倍。导出格式优先给 PNG因为无损如果文件太大再提供 JPEG 选项质量设 0.92 左右肉眼几乎看不出差别。2.3 生成逻辑规则与随机之间的平衡artcraft 如果涉及自动生成那核心问题就是怎么让结果既有变化又不失控。纯随机出来的东西往往很丑纯规则又太死板。我的经验是采用“受控随机”——先定几个硬性规则再在规则允许的范围内引入随机。举个例子假设你要生成一组圆形图案。硬性规则可以是所有圆必须落在画布内、圆之间不能重叠超过 30%、整体重心偏向画面中心。在这些规则下随机决定每个圆的位置、大小和颜色。这样出来的结果每次都不一样但整体观感是稳定的。实现上我习惯用一个简单的伪随机函数而不是直接调Math.random()。因为伪随机可以设种子同样的种子出同样的结果方便调试和复现。一个最简的种子随机实现大概是这样function seededRandom(seed) { let x Math.sin(seed) * 10000; return x - Math.floor(x); }这个函数不完美但足够用。每次生成时把种子存下来用户如果喜欢某个结果可以记住种子号下次输入同样的种子就能复现。这个功能在创作类工具里特别受欢迎因为它给了用户一种“可掌控的偶然”。3. 技术选型为什么我最终选了这套组合3.1 渲染方式Canvas 还是 SVG这是做视觉类项目第一个要面对的选择。Canvas 和 SVG 各有优劣我列个表对比一下维度CanvasSVG渲染方式像素级绘制矢量描述大量元素性能好一般元素多了会卡事件绑定需要手动计算坐标每个元素可单独绑定导出图片直接 toDataURL需要序列化再转换缩放清晰度放大后模糊无限清晰适合场景粒子、滤镜、高频重绘图标、图表、少量交互元素artcraft 如果偏向生成艺术、粒子效果、实时滤镜Canvas 是更合适的选择。如果偏向可编辑的图形、每个元素都要能点能拖SVG 更省事。我自己的项目里如果是“生成后欣赏”为主选 Canvas如果是“生成后继续编辑”为主选 SVG。还有一个折中方案用 Canvas 做渲染但维护一个数据结构来描述每个元素。这样既有了 Canvas 的性能又能在需要的时候把数据结构导出成 SVG 或 JSON。这个方案稍微多写一点代码但灵活性高很多。3.2 框架选择轻量优先做这类项目我不建议一上来就上重型框架。React、Vue 当然好但如果你的页面只有一个画布加几个控件引入整个框架的收益并不高。我试过用原生 JavaScript 加少量工具函数整个项目打包出来不到 20KB加载飞快。如果确实需要组件化可以考虑 Preact 或 Alpine.js 这类轻量方案。Preact 的 API 和 React 几乎一样但体积小很多。Alpine.js 更适合以 HTML 为主、少量交互的场景直接在标签上写x-data、x-on就行学习成本很低。状态管理方面artcraft 这类项目通常不需要 Redux 或 Pinia。一个简单的发布订阅模式就够了const state { listeners: [], data: {}, set(key, value) { this.data[key] value; this.listeners.forEach(fn fn(key, value)); }, subscribe(fn) { this.listeners.push(fn); } };所有需要响应变化的地方订阅一下参数一变就重绘。简单直接调试也方便。3.3 构建工具Vite 是当前最省心的选择构建工具我强烈推荐 Vite。它的冷启动速度比 Webpack 快一个数量级热更新几乎是瞬时的。配置文件也简单大部分情况下几行就够// vite.config.js import { defineConfig } from vite; export default defineConfig({ base: ./, build: { outDir: dist, assetsInlineLimit: 4096 } });base: ./这个配置很重要它让打包后的资源用相对路径引用直接双击 HTML 文件也能打开不用起服务器。对于 artcraft 这种可能被用户下载下来离线使用的工具这个细节很关键。4. 从零搭一个 artcraft 类项目的实操步骤4.1 项目初始化与目录结构先建目录我习惯这样组织artcraft/ ├── index.html ├── src/ │ ├── main.js │ ├── renderer.js │ ├── generator.js │ ├── controls.js │ └── utils.js ├── styles/ │ └── main.css └── vite.config.jsrenderer.js负责画布绘制generator.js负责生成逻辑controls.js负责界面控件utils.js放通用函数。这样分的好处是生成逻辑可以独立测试不依赖界面。我经常在 Node 环境里直接跑generator.js批量生成几百个结果挑出好看的参数组合再放到界面上当预设。index.html里放一个画布容器和控件区域div idapp canvas idstage/canvas div idpanel/div /divCSS 方面画布用display: block消除底部间隙容器用 flex 布局让画布和面板并排。面板宽度固定 280px 左右太窄控件挤太宽画布区域小。4.2 画布初始化与自适应处理画布尺寸不能写死。我的做法是监听容器尺寸变化用ResizeObserver来更新画布const canvas document.getElementById(stage); const ctx canvas.getContext(2d); function resize() { const rect canvas.parentElement.getBoundingClientRect(); const dpr window.devicePixelRatio || 1; canvas.width rect.width * dpr; canvas.height rect.height * dpr; canvas.style.width rect.width px; canvas.style.height rect.height px; ctx.scale(dpr, dpr); draw(); } const observer new ResizeObserver(resize); observer.observe(canvas.parentElement);这里有个关键点devicePixelRatio。在高分屏上如果不用 dpr 缩放画布会模糊。但缩放之后所有绘制坐标都要按逻辑像素来算不能直接用canvas.width。我一般在draw()函数开头重置变换矩阵然后按逻辑宽高来画。4.3 生成器的编写与参数暴露生成器我习惯写成一个纯函数输入参数对象输出一个元素数组。这样它不碰 DOM也不碰画布纯粹是数据变换export function generate(params) { const { seed, count, minSize, maxSize, palette } params; const rand seededRandom(seed); const elements []; for (let i 0; i count; i) { elements.push({ x: rand() * 100, y: rand() * 100, size: minSize rand() * (maxSize - minSize), color: palette[Math.floor(rand() * palette.length)], rotation: rand() * Math.PI * 2 }); } return elements; }参数暴露给界面时每个参数配一个说明文字。说明文字不要写“参数一”“参数二”要写人话。比如count写成“元素数量”minSize写成“最小尺寸”。用户看到能理解才愿意调。4.4 控件绑定与实时重绘控件我用原生 input 元素不引入 UI 库。滑块用input typerange颜色用input typecolor数值用input typenumber。每个控件绑定一个input事件事件里更新参数对象然后调draw()。function bindControl(id, key, transform) { const el document.getElementById(id); el.addEventListener(input, () { const value transform ? transform(el.value) : el.value; params[key] value; scheduleDraw(); }); }scheduleDraw()里做防抖let rafId null; function scheduleDraw() { if (rafId) return; rafId requestAnimationFrame(() { rafId null; draw(); }); }这样连续拖动滑块时每帧最多重绘一次不会卡顿。5. 实测中遇到的坑与排查过程5.1 画布模糊dpr 没处理干净最开始我按逻辑像素设了画布宽高没乘 dpr结果在高分屏上整个画面像蒙了一层雾。排查的时候我先怀疑是 CSS 滤镜查了半天没有又怀疑是颜色值问题换了纯黑纯白还是一样。后来用window.devicePixelRatio打印了一下发现是 2才意识到画布的实际像素只有显示尺寸的一半。修复方法就是前面说的canvas.width rect.width * dpr然后ctx.scale(dpr, dpr)。但这里有个后续问题如果resize被多次触发ctx.scale会累加。所以每次 resize 前要先ctx.setTransform(1, 0, 0, 1, 0, 0)重置。这个坑我踩了两次才记住。5.2 导出图片空白异步绘制没完成导出功能我一开始写成function exportImage() { const url canvas.toDataURL(image/png); download(url); }结果有时候导出的图是空白的。排查发现如果draw()里有异步操作比如加载字体、图片toDataURL可能在绘制完成前就执行了。解决办法是把导出逻辑放到绘制完成的回调里或者用一个标志位标记绘制状态导出前检查。更稳的做法是导出时重新跑一遍同步绘制流程不依赖屏幕上的画布状态。我后来专门写了一个renderToCanvas(params, width, height)函数导出时新建一个离屏画布按导出尺寸重新画一遍。这样既解决了时序问题又能控制导出分辨率。5.3 参数联动导致死循环有一次我做了两个联动参数A 变化时更新 BB 变化时更新 A。结果拖动 A 的时候A 更新 BB 又更新 A无限循环页面直接卡死。排查的时候看控制台没有报错就是卡住不动。后来在更新函数里加了个isUpdating标志位才定位到。修复方案有两种一是加标志位更新期间忽略反向更新二是改成单向数据流A 只读不写B 根据 A 计算得出不反向影响 A。我后来选了第二种因为逻辑更清晰不容易出问题。这个教训是联动参数尽量做成单向依赖不要互相写。5.4 移动端触摸事件与画布滚动冲突在手机上测试时手指在画布上滑动页面跟着滚画布上的交互完全没法用。原因是触摸事件默认会触发页面滚动。解决办法是在画布的触摸事件里调preventDefault()同时 CSS 加touch-action: none。#stage { touch-action: none; }但这样又带来一个新问题如果画布占满屏幕用户就没法滚动页面了。所以画布区域不能太大或者要在画布外留出可滚动区域。我的做法是画布高度不超过视口高度的 70%下面留出控件区域用户可以在控件区域滚动。6. 让 artcraft 更好用的几个进阶思路6.1 预设系统降低上手门槛不是每个用户都愿意调参数。预设系统能让用户一键得到不错的结果。预设的实现很简单就是一组参数组合const presets { 柔和: { count: 30, minSize: 5, maxSize: 20, palette: [#a8d8ea, #aa96da, #fcbad3] }, 强烈: { count: 80, minSize: 2, maxSize: 40, palette: [#ff5722, #ffc107, #000000] }, 极简: { count: 12, minSize: 10, maxSize: 30, palette: [#333333, #ffffff, #e0e0e0] } };预设名字要用感性词不要用“预设一”“预设二”。用户看到“柔和”“强烈”“极简”能立刻知道大概是什么感觉。点击预设后把参数写回控件触发重绘。这个功能开发成本很低但体验提升很明显。6.2 种子分享让结果可复现前面提到的种子机制可以进一步做成分享功能。用户调出一个满意的结果后点“分享”生成一个带种子和参数的链接。别人打开链接看到一模一样的结果。实现上就是把参数对象序列化成 URL 查询字符串function share() { const query new URLSearchParams(params).toString(); const url location.origin location.pathname ? query; navigator.clipboard.writeText(url); }页面加载时解析查询字符串如果有参数就应用。这个功能在创作社区里很受欢迎因为它让“偶然得到的好结果”可以被保存和传播。6.3 批量导出一次生成多张有时候用户想要一组风格一致但细节不同的图。批量导出就是按不同种子连续生成多张打包下载。实现上可以用JSZip这类库把多张 PNG 打成一个 zip。注意每张图之间要留一点时间间隔或者用离屏画布同步生成避免阻塞主线程。async function batchExport(count) { const zip new JSZip(); for (let i 0; i count; i) { const p { ...params, seed: params.seed i }; const blob await renderToBlob(p, 1600, 1200); zip.file(artcraft-${i}.png, blob); } const content await zip.generateAsync({ type: blob }); download(content, artcraft-batch.zip); }批量数量不要设太大我一般限制在 20 张以内。再多的话生成时间和文件体积都会让用户等得不耐烦。6.4 性能优化离屏画布与分层绘制当元素数量超过几百个时每帧全量重绘会开始卡。优化思路是分层把不常变的部分画到一个离屏画布上每帧只重绘变化的部分。比如背景和静态装饰画一次动态元素每帧重绘。const bgCanvas document.createElement(canvas); const bgCtx bgCanvas.getContext(2d); function renderBackground() { bgCtx.clearRect(0, 0, bgCanvas.width, bgCanvas.height); // 画背景 } function draw() { ctx.drawImage(bgCanvas, 0, 0); // 画动态元素 }背景只在参数变化时重绘动态元素每帧重绘。这样即使元素很多帧率也能稳住。实测下来从 200 个元素开始卡优化后 800 个元素还能保持流畅。7. 一些个人体会和后续可玩的方向做 artcraft 这类项目我最大的体会是不要一开始就追求完美。先让一个最简版本跑起来哪怕只能画几个圆然后在这个基础上一点点加。每加一个功能就实际用一下感受哪里别扭。很多设计决策不是想出来的是用出来的。另一个体会是参数默认值比参数范围更重要。用户打开页面看到的第一眼决定了他是继续玩还是关掉。默认值要调到“看起来已经不错”的状态让用户觉得“这个工具有点东西”然后才愿意去调。后续可玩的方向我觉得有几个值得试。一是引入图层概念让用户能把不同生成结果叠加像做拼贴一样。二是加一个简单的动画循环让静态图案动起来哪怕只是缓慢旋转或呼吸缩放。三是做参数随机化按钮一键把所有参数随机一遍适合找灵感。这些功能都不复杂但能让工具的创作空间大很多。最后分享一个小技巧如果你也在做类似的生成类工具建议在开发阶段加一个“调试模式”按某个快捷键显示当前所有参数值和种子号。调试的时候不用来回翻代码直接看屏幕就知道当前状态。这个功能上线前记得隐藏或去掉但开发期间能省很多时间。
1. 从“artcraft”这个名字说起它到底想解决什么问题第一次看到“artcraft”这个词我脑子里蹦出来的不是某个具体工具而是一种很朴素的组合感——art 加上 craft艺术加手艺。这两个词放在一起本身就带着一种张力一边是偏感性、偏表达的创作冲动另一边是偏理性、偏流程的工程化落地。很多做内容、做设计、做小工具的人卡住的地方恰恰就在这两者之间——脑子里有画面手上却拼不出一个能跑、能看、能交付的东西。我接触过不少独立开发者和小团队他们做项目的起点往往不是“我要造一个多牛的系统”而是“我想把某个想法快速变成能看的东西”。这个“能看的东西”可能是一个作品集页面、一个交互式的小玩具、一个带视觉风格的数据展示甚至只是一个能自动生成某种图案的脚本。artcraft 这个标题给我的直觉就是冲着这类需求去的它不追求大而全而是想把“艺术表达”和“手工实现”这两件事捏在一起让创作者不用在审美和代码之间反复横跳。关键词和摘要描述虽然留空但从标题本身能反推出几个核心方向。第一它大概率涉及视觉生成或视觉组织因为 art 这个词天然指向图形、色彩、排版、动效这些看得见的东西。第二craft 暗示了可操作性和过程感不是纯理论而是有步骤、有工具、有手感的实践。第三这类项目通常面向的读者是有一定动手意愿但未必是资深工程师的人比如设计师想学点代码、前端想补点审美、内容创作者想搞点自动化的小玩意。所以这篇博文我不打算把它写成一份冷冰冰的 API 文档而是按一个真实做过类似项目的人的视角把 artcraft 可能涉及的技术选型、实现路径、踩坑经验和扩展思路拆开来讲。如果你正好在琢磨怎么把创意变成可运行的东西或者你手里有一个类似“artcraft”定位的小项目想落地下面的内容应该能直接拿去参考。2. 拆解 artcraft 的核心构成视觉、交互与生成逻辑2.1 视觉层为什么“好看”本身就是一个技术问题很多人觉得视觉是设计师的事跟写代码的没关系。但实际做过项目的人都知道一个东西“好不好看”在技术层面是有明确抓手。artcraft 如果涉及视觉输出那它至少要处理三件事布局、色彩和层次。布局不是简单地摆几个 div。以常见的画布类项目为例元素的位置关系决定了视觉动线。我习惯先用一个很笨的办法在纸上画九宫格把主要元素按重要性标进去然后再换算成百分比坐标。这样做的好处是代码里的定位值不是拍脑袋写的而是有视觉依据的。比如一个生成艺术图案的项目中心区域放主体图形四周留白比例控制在 15% 到 20% 之间视觉上会舒服很多。这个比例不是玄学是大量海报和界面设计里反复验证过的经验值。色彩方面artcraft 这类项目最容易踩的坑是“颜色太多”。我见过不少生成类作品每个元素都给了高饱和度颜色结果像打翻了调色盘。比较稳的做法是限定色板主色一个辅助色两个中性色两到三个总共不超过六个。如果你用代码生成颜色可以用 HSL 模式来控制把色相 H 限制在某个区间内饱和度和亮度做小范围浮动。这样出来的颜色既有变化又不会失控。层次感则依赖阴影、透明度和模糊。CSS 里的box-shadow和filter: blur()是性价比最高的两个属性。但要注意阴影不要用纯黑用带一点主色倾向的深色会更自然。比如主色是蓝紫调阴影就用rgba(30, 20, 60, 0.15)这种而不是rgba(0, 0, 0, 0.2)。这个细节很小但做出来的东西质感差别很大。2.2 交互层让“craft”真正被感受到craft 这个词意味着过程感而过程感在数字产品里主要靠交互来传递。artcraft 如果只是一个静态输出那它跟一张图片没区别。真正让它有“手艺”味道的是用户能参与、能调整、能看到变化。常见的交互模式有三种参数调节、实时预览和导出保存。参数调节是最直接的比如滑块控制密度、大小、旋转角度。这里有个经验滑块的范围不要设得太宽。我试过让一个参数从 0 到 1000结果用户根本找不到合适的值。后来改成 0 到 100默认值放在 40 左右使用体验立刻好了很多。默认值的选择也有讲究它应该是“大多数情况下看起来还不错”的那个值而不是中间值。实时预览的关键是防抖。如果每次滑块移动都触发重绘性能会崩。我一般用requestAnimationFrame配合一个简单的节流逻辑保证每帧最多重绘一次。对于计算量大的生成逻辑还会加一个 100 到 200 毫秒的延迟等用户停下来了再算最终结果。这个延迟不能太长否则会觉得卡也不能太短否则等于没防抖。导出保存看起来简单但坑不少。如果画布内容是动态生成的导出时要注意分辨率。屏幕上的 800x600 导出成图片可能只有 72dpi打印或放大就糊了。我的做法是维护一个“导出比例”参数默认 2 倍用户有需要可以调到 4 倍。导出格式优先给 PNG因为无损如果文件太大再提供 JPEG 选项质量设 0.92 左右肉眼几乎看不出差别。2.3 生成逻辑规则与随机之间的平衡artcraft 如果涉及自动生成那核心问题就是怎么让结果既有变化又不失控。纯随机出来的东西往往很丑纯规则又太死板。我的经验是采用“受控随机”——先定几个硬性规则再在规则允许的范围内引入随机。举个例子假设你要生成一组圆形图案。硬性规则可以是所有圆必须落在画布内、圆之间不能重叠超过 30%、整体重心偏向画面中心。在这些规则下随机决定每个圆的位置、大小和颜色。这样出来的结果每次都不一样但整体观感是稳定的。实现上我习惯用一个简单的伪随机函数而不是直接调Math.random()。因为伪随机可以设种子同样的种子出同样的结果方便调试和复现。一个最简的种子随机实现大概是这样function seededRandom(seed) { let x Math.sin(seed) * 10000; return x - Math.floor(x); }这个函数不完美但足够用。每次生成时把种子存下来用户如果喜欢某个结果可以记住种子号下次输入同样的种子就能复现。这个功能在创作类工具里特别受欢迎因为它给了用户一种“可掌控的偶然”。3. 技术选型为什么我最终选了这套组合3.1 渲染方式Canvas 还是 SVG这是做视觉类项目第一个要面对的选择。Canvas 和 SVG 各有优劣我列个表对比一下维度CanvasSVG渲染方式像素级绘制矢量描述大量元素性能好一般元素多了会卡事件绑定需要手动计算坐标每个元素可单独绑定导出图片直接 toDataURL需要序列化再转换缩放清晰度放大后模糊无限清晰适合场景粒子、滤镜、高频重绘图标、图表、少量交互元素artcraft 如果偏向生成艺术、粒子效果、实时滤镜Canvas 是更合适的选择。如果偏向可编辑的图形、每个元素都要能点能拖SVG 更省事。我自己的项目里如果是“生成后欣赏”为主选 Canvas如果是“生成后继续编辑”为主选 SVG。还有一个折中方案用 Canvas 做渲染但维护一个数据结构来描述每个元素。这样既有了 Canvas 的性能又能在需要的时候把数据结构导出成 SVG 或 JSON。这个方案稍微多写一点代码但灵活性高很多。3.2 框架选择轻量优先做这类项目我不建议一上来就上重型框架。React、Vue 当然好但如果你的页面只有一个画布加几个控件引入整个框架的收益并不高。我试过用原生 JavaScript 加少量工具函数整个项目打包出来不到 20KB加载飞快。如果确实需要组件化可以考虑 Preact 或 Alpine.js 这类轻量方案。Preact 的 API 和 React 几乎一样但体积小很多。Alpine.js 更适合以 HTML 为主、少量交互的场景直接在标签上写x-data、x-on就行学习成本很低。状态管理方面artcraft 这类项目通常不需要 Redux 或 Pinia。一个简单的发布订阅模式就够了const state { listeners: [], data: {}, set(key, value) { this.data[key] value; this.listeners.forEach(fn fn(key, value)); }, subscribe(fn) { this.listeners.push(fn); } };所有需要响应变化的地方订阅一下参数一变就重绘。简单直接调试也方便。3.3 构建工具Vite 是当前最省心的选择构建工具我强烈推荐 Vite。它的冷启动速度比 Webpack 快一个数量级热更新几乎是瞬时的。配置文件也简单大部分情况下几行就够// vite.config.js import { defineConfig } from vite; export default defineConfig({ base: ./, build: { outDir: dist, assetsInlineLimit: 4096 } });base: ./这个配置很重要它让打包后的资源用相对路径引用直接双击 HTML 文件也能打开不用起服务器。对于 artcraft 这种可能被用户下载下来离线使用的工具这个细节很关键。4. 从零搭一个 artcraft 类项目的实操步骤4.1 项目初始化与目录结构先建目录我习惯这样组织artcraft/ ├── index.html ├── src/ │ ├── main.js │ ├── renderer.js │ ├── generator.js │ ├── controls.js │ └── utils.js ├── styles/ │ └── main.css └── vite.config.jsrenderer.js负责画布绘制generator.js负责生成逻辑controls.js负责界面控件utils.js放通用函数。这样分的好处是生成逻辑可以独立测试不依赖界面。我经常在 Node 环境里直接跑generator.js批量生成几百个结果挑出好看的参数组合再放到界面上当预设。index.html里放一个画布容器和控件区域div idapp canvas idstage/canvas div idpanel/div /divCSS 方面画布用display: block消除底部间隙容器用 flex 布局让画布和面板并排。面板宽度固定 280px 左右太窄控件挤太宽画布区域小。4.2 画布初始化与自适应处理画布尺寸不能写死。我的做法是监听容器尺寸变化用ResizeObserver来更新画布const canvas document.getElementById(stage); const ctx canvas.getContext(2d); function resize() { const rect canvas.parentElement.getBoundingClientRect(); const dpr window.devicePixelRatio || 1; canvas.width rect.width * dpr; canvas.height rect.height * dpr; canvas.style.width rect.width px; canvas.style.height rect.height px; ctx.scale(dpr, dpr); draw(); } const observer new ResizeObserver(resize); observer.observe(canvas.parentElement);这里有个关键点devicePixelRatio。在高分屏上如果不用 dpr 缩放画布会模糊。但缩放之后所有绘制坐标都要按逻辑像素来算不能直接用canvas.width。我一般在draw()函数开头重置变换矩阵然后按逻辑宽高来画。4.3 生成器的编写与参数暴露生成器我习惯写成一个纯函数输入参数对象输出一个元素数组。这样它不碰 DOM也不碰画布纯粹是数据变换export function generate(params) { const { seed, count, minSize, maxSize, palette } params; const rand seededRandom(seed); const elements []; for (let i 0; i count; i) { elements.push({ x: rand() * 100, y: rand() * 100, size: minSize rand() * (maxSize - minSize), color: palette[Math.floor(rand() * palette.length)], rotation: rand() * Math.PI * 2 }); } return elements; }参数暴露给界面时每个参数配一个说明文字。说明文字不要写“参数一”“参数二”要写人话。比如count写成“元素数量”minSize写成“最小尺寸”。用户看到能理解才愿意调。4.4 控件绑定与实时重绘控件我用原生 input 元素不引入 UI 库。滑块用input typerange颜色用input typecolor数值用input typenumber。每个控件绑定一个input事件事件里更新参数对象然后调draw()。function bindControl(id, key, transform) { const el document.getElementById(id); el.addEventListener(input, () { const value transform ? transform(el.value) : el.value; params[key] value; scheduleDraw(); }); }scheduleDraw()里做防抖let rafId null; function scheduleDraw() { if (rafId) return; rafId requestAnimationFrame(() { rafId null; draw(); }); }这样连续拖动滑块时每帧最多重绘一次不会卡顿。5. 实测中遇到的坑与排查过程5.1 画布模糊dpr 没处理干净最开始我按逻辑像素设了画布宽高没乘 dpr结果在高分屏上整个画面像蒙了一层雾。排查的时候我先怀疑是 CSS 滤镜查了半天没有又怀疑是颜色值问题换了纯黑纯白还是一样。后来用window.devicePixelRatio打印了一下发现是 2才意识到画布的实际像素只有显示尺寸的一半。修复方法就是前面说的canvas.width rect.width * dpr然后ctx.scale(dpr, dpr)。但这里有个后续问题如果resize被多次触发ctx.scale会累加。所以每次 resize 前要先ctx.setTransform(1, 0, 0, 1, 0, 0)重置。这个坑我踩了两次才记住。5.2 导出图片空白异步绘制没完成导出功能我一开始写成function exportImage() { const url canvas.toDataURL(image/png); download(url); }结果有时候导出的图是空白的。排查发现如果draw()里有异步操作比如加载字体、图片toDataURL可能在绘制完成前就执行了。解决办法是把导出逻辑放到绘制完成的回调里或者用一个标志位标记绘制状态导出前检查。更稳的做法是导出时重新跑一遍同步绘制流程不依赖屏幕上的画布状态。我后来专门写了一个renderToCanvas(params, width, height)函数导出时新建一个离屏画布按导出尺寸重新画一遍。这样既解决了时序问题又能控制导出分辨率。5.3 参数联动导致死循环有一次我做了两个联动参数A 变化时更新 BB 变化时更新 A。结果拖动 A 的时候A 更新 BB 又更新 A无限循环页面直接卡死。排查的时候看控制台没有报错就是卡住不动。后来在更新函数里加了个isUpdating标志位才定位到。修复方案有两种一是加标志位更新期间忽略反向更新二是改成单向数据流A 只读不写B 根据 A 计算得出不反向影响 A。我后来选了第二种因为逻辑更清晰不容易出问题。这个教训是联动参数尽量做成单向依赖不要互相写。5.4 移动端触摸事件与画布滚动冲突在手机上测试时手指在画布上滑动页面跟着滚画布上的交互完全没法用。原因是触摸事件默认会触发页面滚动。解决办法是在画布的触摸事件里调preventDefault()同时 CSS 加touch-action: none。#stage { touch-action: none; }但这样又带来一个新问题如果画布占满屏幕用户就没法滚动页面了。所以画布区域不能太大或者要在画布外留出可滚动区域。我的做法是画布高度不超过视口高度的 70%下面留出控件区域用户可以在控件区域滚动。6. 让 artcraft 更好用的几个进阶思路6.1 预设系统降低上手门槛不是每个用户都愿意调参数。预设系统能让用户一键得到不错的结果。预设的实现很简单就是一组参数组合const presets { 柔和: { count: 30, minSize: 5, maxSize: 20, palette: [#a8d8ea, #aa96da, #fcbad3] }, 强烈: { count: 80, minSize: 2, maxSize: 40, palette: [#ff5722, #ffc107, #000000] }, 极简: { count: 12, minSize: 10, maxSize: 30, palette: [#333333, #ffffff, #e0e0e0] } };预设名字要用感性词不要用“预设一”“预设二”。用户看到“柔和”“强烈”“极简”能立刻知道大概是什么感觉。点击预设后把参数写回控件触发重绘。这个功能开发成本很低但体验提升很明显。6.2 种子分享让结果可复现前面提到的种子机制可以进一步做成分享功能。用户调出一个满意的结果后点“分享”生成一个带种子和参数的链接。别人打开链接看到一模一样的结果。实现上就是把参数对象序列化成 URL 查询字符串function share() { const query new URLSearchParams(params).toString(); const url location.origin location.pathname ? query; navigator.clipboard.writeText(url); }页面加载时解析查询字符串如果有参数就应用。这个功能在创作社区里很受欢迎因为它让“偶然得到的好结果”可以被保存和传播。6.3 批量导出一次生成多张有时候用户想要一组风格一致但细节不同的图。批量导出就是按不同种子连续生成多张打包下载。实现上可以用JSZip这类库把多张 PNG 打成一个 zip。注意每张图之间要留一点时间间隔或者用离屏画布同步生成避免阻塞主线程。async function batchExport(count) { const zip new JSZip(); for (let i 0; i count; i) { const p { ...params, seed: params.seed i }; const blob await renderToBlob(p, 1600, 1200); zip.file(artcraft-${i}.png, blob); } const content await zip.generateAsync({ type: blob }); download(content, artcraft-batch.zip); }批量数量不要设太大我一般限制在 20 张以内。再多的话生成时间和文件体积都会让用户等得不耐烦。6.4 性能优化离屏画布与分层绘制当元素数量超过几百个时每帧全量重绘会开始卡。优化思路是分层把不常变的部分画到一个离屏画布上每帧只重绘变化的部分。比如背景和静态装饰画一次动态元素每帧重绘。const bgCanvas document.createElement(canvas); const bgCtx bgCanvas.getContext(2d); function renderBackground() { bgCtx.clearRect(0, 0, bgCanvas.width, bgCanvas.height); // 画背景 } function draw() { ctx.drawImage(bgCanvas, 0, 0); // 画动态元素 }背景只在参数变化时重绘动态元素每帧重绘。这样即使元素很多帧率也能稳住。实测下来从 200 个元素开始卡优化后 800 个元素还能保持流畅。7. 一些个人体会和后续可玩的方向做 artcraft 这类项目我最大的体会是不要一开始就追求完美。先让一个最简版本跑起来哪怕只能画几个圆然后在这个基础上一点点加。每加一个功能就实际用一下感受哪里别扭。很多设计决策不是想出来的是用出来的。另一个体会是参数默认值比参数范围更重要。用户打开页面看到的第一眼决定了他是继续玩还是关掉。默认值要调到“看起来已经不错”的状态让用户觉得“这个工具有点东西”然后才愿意去调。后续可玩的方向我觉得有几个值得试。一是引入图层概念让用户能把不同生成结果叠加像做拼贴一样。二是加一个简单的动画循环让静态图案动起来哪怕只是缓慢旋转或呼吸缩放。三是做参数随机化按钮一键把所有参数随机一遍适合找灵感。这些功能都不复杂但能让工具的创作空间大很多。最后分享一个小技巧如果你也在做类似的生成类工具建议在开发阶段加一个“调试模式”按某个快捷键显示当前所有参数值和种子号。调试的时候不用来回翻代码直接看屏幕就知道当前状态。这个功能上线前记得隐藏或去掉但开发期间能省很多时间。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
