企业官网建设流程全解析

1. 从“artcraft”这个名字说起：它到底想解决什么问题

第一次看到“artcraft”这个标题，我脑子里蹦出来的第一反应是：这大概率不是一个单纯的绘画工具，也不是一个纯粹的手工教程合集。它更像是把“art（艺术表达）”和“craft（工艺实现）”这两件事捏在了一起——一边是偏感性的创意输出，一边是偏理性的工程落地。这种组合在近两年的独立项目里越来越常见，原因也很直接：很多人有想法，但卡在“怎么把它做出来”这一步；也有很多人会做东西，但缺一个能持续产出灵感的框架。

我拿到这个标题之后，没有急着去套某个具体的技术栈，而是先把它当成一个“项目代号”来拆。所谓项目代号，就是它不一定直接告诉你用了什么语言、什么框架，但它一定暗示了这个项目的核心气质。artcraft 的气质就是“手作感 + 可复现”。它要解决的核心问题，我判断是这三类：

• 创意到成品的断层：脑子里有一个画面、一个物件、一段交互，但不知道从哪一步开始动手。
• 工具链太散：画图用一个软件，建模用一个，写逻辑又换一个，最后拼不起来。
• 缺少可参考的完整案例：网上教程大多是片段，告诉你“这个按钮怎么点”，但不告诉你“整个东西怎么从零长出来”。

所以这篇内容，我打算按一个真实项目复现的思路来写。适合谁看？如果你是那种“有点想法、会一点基础操作、但没完整做过一个 artcraft 类项目”的人，这篇会比较对路。如果你已经是老手，也可以直接跳到第 3 和第 4 部分，那里有我踩过的坑和参数取舍的细节。

提示：下文提到的所有工具、参数、目录结构，都是基于常见实践给出的参考方案，不是唯一解。你可以根据自己熟悉的生态替换，但思路尽量保持一致。

2. 整体设计与思路拆解：为什么我不建议一上来就写代码

2.1 先定“输出物”，再定“输入物”

很多新手做 artcraft 类项目，最容易犯的错就是先打开编辑器，然后对着空白页面发呆。我的习惯是反过来的：先明确最终要交付什么。是一个可交互的网页？是一组可打印的图案？还是一个能批量生成变体的脚本？输出物不同，后面的技术选型完全不一样。

我拿一个最常见的场景举例：假设你要做的是一个“生成式装饰图案工具”，用户输入几个参数，就能得到一张可以导出为 SVG 的图案。这个输出物决定了三件事：

1. 必须用矢量格式，因为要保证放大不糊，所以 SVG 是首选，PNG 只能作为预览。
2. 参数不能太多，超过 6 个滑块，普通用户就晕了，所以要做预设。
3. 必须能一键导出，否则用户玩两下就走了。

你看，定完输出物，输入物的范围就收窄了。这就是“先定终点”的好处。

2.2 技术选型：为什么我偏向“轻前端 + 纯函数”

artcraft 类项目有一个特点：它的核心逻辑往往是“变换”和“组合”，而不是“增删改查”。这种逻辑最适合用纯函数来表达。所谓纯函数，就是同样的输入永远得到同样的输出，不依赖外部状态。这样做的好处是：

• 可测试：你给一组参数，跑出来一张图，换台机器跑结果一样。
• 可复现：用户分享一组参数，别人打开就能看到一模一样的图案。
• 好调试：出问题了，只需要看输入和输出，不用追一堆全局变量。

具体到技术栈，我一般会这样搭：

这个表格不是让你照抄，而是让你看到每一层都有明确的“为什么”。如果你选 React，那交互层就换成 React 的状态管理，但逻辑层依然建议保持纯函数。

2.3 目录结构：让“art”和“craft”分开住

我见过很多项目，把绘图逻辑、参数面板、导出逻辑全塞在一个文件里，超过 500 行之后就没法看了。artcraft 这个名字本身就提示了拆分方式：art 相关的放一起，craft 相关的放一起。

一个我常用的结构是这样的：

artcraft/ ├── src/ │ ├── art/ # 创意相关：调色、构图、随机种子 │ │ ├── palette.js │ │ ├── composition.js │ │ └── seed.js │ ├── craft/ # 工程相关：渲染、导出、性能 │ │ ├── renderer.js │ │ ├── exporter.js │ │ └── throttle.js │ ├── presets/ # 预设参数，方便用户一键切换 │ └── main.js # 只做组装，不写具体逻辑 ├── index.html └── package.json

这样拆的好处是，当你想换一种渲染方式（比如从 Canvas 换到 SVG），只需要动 craft/renderer.js，art 目录里的东西完全不用碰。这就是“关注点分离”在实际项目里的落地。

3. 核心细节解析与实操要点：参数、种子与性能

3.1 随机种子：让“随机”变得可复现

artcraft 类项目几乎都会用到随机。但真正的随机（Math.random）有个致命问题：每次刷新结果都不一样，用户没办法分享，你也没办法调试。所以我的做法是引入一个“种子随机数生成器”。

原理不复杂，你可以把它理解成一个“带记忆的骰子”。普通的骰子每次掷都是独立的，而种子骰子会根据你给的初始值，生成一串固定的序列。常用的算法是 Mulberry32，代码很短：

function mulberry32(seed) { return function() { seed |= 0; seed = seed + 0x6D2B79F5 | 0; let t = Math.imul(seed ^ seed >>> 15, 1 | seed); t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t; return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }

用的时候，你只需要把用户输入的种子（比如一个字符串）转成数字，然后传给这个函数，后面所有随机都从这里取。这样用户只要记住种子，就能复现一模一样的图案。

注意：种子不要直接用 Math.random 生成，否则你每次打开页面看到的默认图案都在变，用户会以为你的工具不稳定。我一般默认给一个固定值，比如 20240501，然后提供一个“换一批”按钮让用户主动触发。

3.2 参数设计：少即是多，但要留“高级模式”

参数面板是 artcraft 类项目最容易做砸的地方。我踩过的坑是：一开始给了 12 个滑块，结果用户根本不知道每个是干嘛的，调两下就放弃了。后来我改成“基础模式 + 高级模式”两层：

• 基础模式：只留 3 到 4 个最直观的参数，比如“密度”“大小”“配色方案”。
• 高级模式：折叠起来，放种子、偏移量、旋转角度这些。

这样做的好处是，新手能快速出图，老手能精细控制。而且基础模式的参数最好做成“离散档位”而不是连续滑块，比如密度只有“稀疏 / 适中 / 密集”三档，用户更容易理解。

3.3 性能：什么时候该用 Canvas，什么时候该用 SVG

这个问题我被问过很多次。我的经验判断标准很简单：

• 图元数量小于 500，且需要单独交互（比如点击某个图形变色），用 SVG。
• 图元数量大于 500，或者需要频繁重绘，用 Canvas。
• 如果两者都要，那就用 Canvas 渲染，用一层透明的 SVG 做交互热区。

为什么是 500 这个量级？因为 SVG 每个图元都是一个 DOM 节点，节点多了之后浏览器的布局和重绘开销会明显上升。而 Canvas 是一张位图，图元数量对性能的影响主要在于绘制次数，不在 DOM 层面。实测下来，1000 个圆点在 Canvas 上跑 60 帧很轻松，但在 SVG 上掉到 30 帧以下。

提示：如果你不确定，可以先按 SVG 做，等到卡顿了再换 Canvas。但目录结构要提前分好，否则换渲染方式的时候会改到崩溃。

4. 实操过程与核心环节实现：从零跑通一个最小版本

4.1 第一步：搭一个能看见东西的页面

不要一上来就写逻辑。先写一个最简单的 HTML，放一个 canvas，然后用固定参数画一个圆。这一步的目的是确认你的渲染环境是通的。

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>artcraft 最小版本</title> </head> <body> <canvas id="stage" width="800" height="600"></canvas> <script> const canvas = document.getElementById('stage'); const ctx = canvas.getContext('2d'); ctx.fillStyle = '#2c3e50'; ctx.beginPath(); ctx.arc(400, 300, 100, 0, Math.PI * 2); ctx.fill(); </script> </body> </html>

打开浏览器，看到一个圆，说明环境没问题。这一步看起来很简单，但很多人跳过它，直接写复杂逻辑，结果出问题的时候不知道是渲染坏了还是逻辑坏了。

4.2 第二步：把“画一个圆”变成“画一组圆”

接下来引入种子和循环。我一般会先定义一个“图元生成函数”，它接收种子和参数，返回一组图元数据，然后再写一个“渲染函数”，把图元数据画出来。这样逻辑和渲染就分开了。

function generateShapes(seed, count, radius) { const rand = mulberry32(seed); const shapes = []; for (let i = 0; i < count; i++) { shapes.push({ x: rand() * 800, y: rand() * 600, r: radius * (0.5 + rand()), hue: rand() * 360 }); } return shapes; } function renderShapes(ctx, shapes) { ctx.clearRect(0, 0, 800, 600); shapes.forEach(s => { ctx.fillStyle = `hsl(${s.hue}, 70%, 60%)`; ctx.beginPath(); ctx.arc(s.x, s.y, s.r, 0, Math.PI * 2); ctx.fill(); }); }

这时候你改一下种子，就能看到完全不同的图案。这就是“可复现的随机”带来的好处。

4.3 第三步：加参数面板和导出

参数面板我建议用原生 input，不要急着上 UI 库。三个滑块加一个按钮，代码量很少：

<label>数量 <input type="range" id="count" min="10" max="300" value="80"></label> <label>大小 <input type="range" id="radius" min="5" max="40" value="15"></label> <label>种子 <input type="number" id="seed" value="20240501"></label> <button id="export">导出 SVG</button>

导出 SVG 的思路是：不直接导出 Canvas 的位图，而是根据图元数据重新生成一份 SVG 字符串。这样做出来的文件是矢量的，放大不糊，而且体积小。

function exportSVG(shapes) { let svg = '<svg xmlns="http://www.w3.org/2000/svg" width="800" height="600">'; shapes.forEach(s => { svg += `<circle cx="${s.x}" cy="${s.y}" r="${s.r}" fill="hsl(${s.hue},70%,60%)"/>`; }); svg += '</svg>'; const blob = new Blob([svg], {type: 'image/svg+xml'}); const url = URL.createObjectURL(blob); const a = document.createElement('a'); a.href = url; a.download = 'artcraft.svg'; a.click(); URL.revokeObjectURL(url); }

到这里，一个最小可用的 artcraft 工具就成型了。它能生成、能调参、能导出，核心闭环已经跑通。

4.4 第四步：加入“预设”和“分享”

用户玩了几下之后，大概率会想“有没有现成的好看组合”。这时候预设就派上用场了。预设本质上就是一组固定的参数，比如：

点击预设，直接把参数填进面板，用户立刻能看到效果。分享功能则更简单：把当前参数拼成 URL 的 query string，用户复制链接就能分享。比如?count=200&radius=8&seed=1024，打开页面时解析这些参数并应用。

注意：URL 参数一定要做类型转换和范围校验，否则用户手动改一个count=99999，你的页面可能直接卡死。我一般会在解析后加一个 clamp 函数，把数值限制在合理区间。

5. 常见问题与排查技巧实录

5.1 图案每次刷新都不一样

这是最常见的问题，原因几乎都是用了 Math.random 而没有用种子。排查方法很简单：在生成图元的地方打印一下随机值，如果两次刷新打印出来的序列不同，那就是没接种子。解决方式就是前面说的 mulberry32，把种子传进去。

5.2 导出 SVG 后颜色不对

这个坑我踩过。Canvas 里用 hsl 没问题，但导出 SVG 的时候，如果色相值是小数，某些查看器会解析失败。解决办法是在生成 SVG 字符串之前，把数值统一取整。另外，SVG 的 fill 属性不支持hsl(120.5, 70%, 60%)这种带小数的写法，必须写成整数。

5.3 图元多了之后拖动滑块卡顿

这是性能问题。排查思路是：先看是生成慢还是渲染慢。你可以在 generateShapes 和 renderShapes 前后各打一个时间戳。如果生成慢，说明循环里的计算太重；如果渲染慢，说明图元太多。对应的解决方式：

• 生成慢：把一些不变的计算提到循环外面，比如颜色字符串的拼接。
• 渲染慢：换 Canvas，或者加一个“预览模式”，拖动时只画 1/4 的图元，松手后再画全量。

5.4 常见问题速查表

5.5 一个容易被忽略的细节：设备像素比

在高分屏上，Canvas 如果不处理 devicePixelRatio，画出来的圆会有点糊。解决方式是在初始化时把 canvas 的宽高乘以像素比，然后用 CSS 把显示尺寸缩回去：

const dpr = window.devicePixelRatio || 1; canvas.width = 800 * dpr; canvas.height = 600 * dpr; canvas.style.width = '800px'; canvas.style.height = '600px'; ctx.scale(dpr, dpr);

这一步不做，导出 SVG 没问题，但屏幕预览会显得不够锐利。很多人以为是浏览器问题，其实是像素比没处理。

6. 后续可以怎么扩展：从玩具到工具

最小版本跑通之后，你可以往几个方向继续加东西。第一个方向是“图层”，让用户可以把不同批次的图元叠在一起，每层单独调参数。第二个方向是“动画”，用 requestAnimationFrame 让种子随时间缓慢变化，图案就会像呼吸一样动起来。第三个方向是“批量导出”，用 Node 跑同一套纯函数，一次生成几百张变体，适合做素材库。

我个人在实际操作中的体会是，artcraft 这类项目最值钱的地方不是代码有多复杂，而是“参数和结果之间的映射关系”调得好不好。同样的算法，参数范围选得对，出来的东西就好看；选得不对，就是一坨。所以多花时间在预设和默认值上，比多写两百行代码更划算。