企业官网建设流程全解析

artcraft 是我业余时间维护的一个浏览器端像素艺术生成工具，核心功能简单到可以用一句话讲完：把一张普通图片丢进页面，拖动几个滑杆，就能得到一张复古像素风格的新图。可以选择像素格子大小、限制颜色数量、开启抖动效果，最后一键导出 PNG。这个项目花了我大概两个周末，不算复杂，但里面对图像处理算法的取舍、性能坑和视觉调优的细节，我觉得比工具本身更值得聊聊，所以整理成这篇东西，希望能给想做类似创意编码、图像处理 Demo 或纯前端小工具的朋友一些参考。

1. 项目起源与设计思路

1.1 为什么我会做一个“像素化”工具

触发这个项目的需求其实特别普通：有一次我想把一张现成的照片做成 8-bit 风格的页面头图，试了一圈现成的在线转换工具，要么水印糊脸，要么生成效果灰蒙蒙的，要么导出的尺寸和颜色数根本不受控。更烦人的是，很多工具的“像素化”其实只是把图片缩小后再放大，颜色完全不可控，出来的效果像一团马赛克，而不是有设计感的像素画。

当时就萌生了一个想法：干脆自己写一个。我要的不是“随机细节丢失”，而是“可控的视觉风格”。具体来说，我需要能控制三个东西：颗粒大小，也就是每个像素方块对应原图多大的区域；颜色数量，让画面看起来不是照片而是插画；以及抖动强度，在减少色彩时保留质感和层次。这三个点其实就是像素艺术生成器最核心的调节维度，artcraft 围绕这三个维度搭了一个非常轻量的 UI，没有后端、没有数据库，打开浏览器就能跑。

我这个构想也参考了一些经典像素艺术的处理流程：先压缩分辨率，再减少颜色，最后可选地做误差扩散。很多成熟的图像处理库比如 Pillow 或者 Photoshop 都内置了类似功能，但浏览器端想要精细控制还得自己写算法。这也是 artcraft 存在的意义：不是再造一个万金油滤镜，而是提供一个面向像素风格的处理管道。

1.2 技术选型：为什么全部跑在浏览器里

artcraft 的技术选型我几乎没有纠结，直接就是纯前端。第一，这个场景压根不需要服务器。图片处理是本地完成的，不涉及用户文件上传，隐私上更安全，我也省掉了一堆文件存储和并发处理的麻烦。第二，现代浏览器的 Canvas API 和相关能力已经足够强，一个 4000x3000 的图片，通过 canvas 读取像素、做算法处理，在全志平台上的耗时基本在一秒量级，完全没有必要为了这种需求去架一个 Python 后端。

具体用到的是 HTML5 Canvas 加 TypeScript。TypeScript 不是必须的，但对于像素操作这种大量使用数组索引的地方，类型检查能减少很多低级错误。例如ImageData.data是一个Uint8ClampedArray，如果你不小心把它当成普通数组来操作，很容易出现越界或者类型转换的问题，有类型标注会舒服很多。

另一个关键选择是不引入任何现成图像处理库。网上有sharp、pngjs、pixelmatch等等，但 artcraft 的目标就是“自己实现核心算法”，这样我可以完整控制每个环节，也能把每一步的数学逻辑讲清楚。对于想学习图像处理的人来说，手写一遍和调库的体验是完全不同的。当然，我用到了浏览器内置的canvas.toDataURL来导出 PNG，这是平台能力，不算第三方依赖。

2. 核心算法与关键实现

2.1 像素化：从“中间点采样”到“区域平均”

artcraft 的第一步是把原图按照设定的像素块大小切分成网格，每个网格最终输出为一个像素块。

最直觉的做法是直接取每个网格左上角或中心点的颜色作为输出。这种策略实现起来最简单，但问题也很明显：如果原图上信息很密集（比如头发丝、树叶），中心点恰好落在一个明暗极端的像素上，最终画面就会出现明显的噪点，看起来不够干净。

我最终采用的是“网格平均”策略：对每个网格块内所有像素的 RGB 通道分别求平均值，作为输出像素的颜色。平均会让结果偏“柔和”，但也更稳定，不容易被单点干扰。如果想让效果更“干脆”，你还可以改成中值，不过中值排序的成本会更高，在实时交互场景下不一定划算。

这里有一个细节：人眼对亮度的感知不是线性的，平均值在数学上很公平，但看起来有时会偏暗。更严谨的做法是做“gamma 校正后的平均”，也就是先把 RGB 值从 sRGB 空间转换到线性空间，平均之后再转回来。

function toLinear(value: number): number { return value / 255 <= 0.04045 ? value / 255 / 12.92 : Math.pow((value / 255 + 0.055) / 1.055, 2.4); } function toSRGB(value: number): number { const linear = Math.max(0, Math.min(1, value)); return linear <= 0.0031308 ? linear * 12.92 * 255 : (1.055 * Math.pow(linear, 1 / 2.4) - 0.055) * 255; }

但这一步不是必须的，如果你的输入图片本身就是 8-bit 色彩，多数时候直接平均也能看。我在 artcraft 里把它做成一个可选开关，默认打开“亮度校正”，效果会更接近真实视觉。

2.2 颜色量化：怎么把成千上万种颜色限制到几个色块

拿到平均颜色之后，图片的色彩数量通常还是很多的。像素艺术之所以有那种“复古感”，很重要的一点是颜色数量非常有限：Game Boy 只有 4 级灰度，FC 红白机常见颜色也不多。所以 artcraft 的核心削弱手段是颜色量化，让整张图只有 N 种颜色。

最简单的量化方式是把 RGB 空间切成固定格子，比如每个通道保留 4 个级别，那么最多 64 种颜色。这种方案快，但问题是有可能很多颜色落在同一个格子附近，浪费了有限的色表，而画面中某些饱和的颜色又找不到合适的映射。

我采用的是更经典的中位切分算法。大致流程是：先把图片中出现的所有颜色当作三维空间里的点，放进一个“颜色桶”里，然后递归地把当前桶中范围最大的那条颜色轴找出来，沿着这条轴把所有点排序，从中间切成两个新桶。重复这个过程，直到桶的数量达到你期望的颜色数。最后对每个桶里的颜色求平均，得到调色板。

这个算法实现起来不复杂，而且效果非常稳定。它的另一个好处是：只要有足够多的桶，画面细节就不会丢太多。我在 artcraft 里默认把颜色数控制在 16 到 32，这个范围最像早期游戏机的视觉风格。

关键代码可以用递归来表达：

function quantize(pixels: Uint8ClampedArray, maxColors: number): RGBColor[] { let bucket: RGBColor[] = []; for (let i = 0; i < pixels.length; i += 4) { bucket.push({ r: pixels[i], g: pixels[i + 1], b: pixels[i + 2] }); } const buckets = splitBucket([bucket], maxColors); return buckets.map((group) => { const sum = group.reduce( (acc, c) => { acc.r += c.r; acc.g += c.g; acc.b += c.b; return acc; }, { r: 0, g: 0, b: 0 } ); const len = group.length; return { r: Math.round(sum.r / len), g: Math.round(sum.g / len), b: Math.round(sum.b / len), }; }); } function splitBucket(buckets: RGBColor[][], max: number): RGBColor[][] { while (buckets.length < max) { let widestIndex = 0; let widestRange = -1; for (let i = 0; i < buckets.length; i++) { const range = getChannelRange(buckets[i]); if (range.value > widestRange) { widestRange = range.value; widestIndex = i; } } if (widestRange === 0) break; const bucket = buckets.splice(widestIndex, 1)[0]; bucket.sort((a, b) => widestChannel === 'r' ? a.r - b.r : widestChannel === 'g' ? a.g - b.g : a.b - b.b ); const mid = Math.floor(bucket.length / 2); buckets.push(bucket.slice(0, mid), bucket.slice(mid)); } return buckets; }

上面是示意代码，实际项目中getChannelRange还需要返回具体是哪个通道的范围最大。这个细节直接影响切分效果：如果你总是优先切 R 通道，那么绿色和蓝色差异很大的画面可能切分得不够合理。正确的判断应该动态选择范围最大的通道，这样才能让每一种颜色都尽量被照顾到。

2.3 抖动：用误差扩散拯救色阶断层

量化之后，最常遇到的视觉问题是“色带”，也就是原本平滑的渐变区域会变成一圈一圈的同心圆。比如天空从浅蓝到深蓝，如果只取 8 种蓝色，就会出现明显的断层。抖动的意义在于，用像素的随机分布来模拟中间过渡色，让渐变看着更自然。

艺术史上已经有一套经典的算法，最常用于游戏和小型嵌入式设备的就是 Floyd-Steinberg 误差扩散。它的核心思想是：当前像素取量化后的颜色时会产生一个“量化误差”，也就是原始颜色和最终颜色之间的差。这个误差不能丢掉，而是按照一定比例分配到右边、右下、下方、左下四个邻居像素上。通过这种方式，误差被传播到整个图像，视觉上误差被“平均”了。

Floyd-Steinberg 的典型扩散矩阵是：

X 7 3 5 1

对应比例是7/16到右边，3/16到下方，5/16到右下，1/16到左下。

在 artcraft 里，我实现了它，但做了一点小改动：因为像素化操作在前，所以误差扩散应该作用在“像素块”级别的数据上，而不是原始像素上。也就是说，当我把某个像素块的颜色映射到调色板中最接近的颜色后，把误差加到周围像素块上。这样抖动和前面的像素化是协调的，不会互相打架。

实现时要注意避免相邻像素块被重复处理。通常的做法是逐行从左到右处理，处理过的像素不再回头。如果把误差传播到已经处理过的像素，就会导致累积误差，画面会变得花。这个问题也是我在初期经常遇到的。

for (let y = 0; y < height; y++) { for (let x = 0; x < width; x++) { const oldR = blockColors[y * width + x].r; const oldG = blockColors[y * width + x].g; const oldB = blockColors[y * width + x].b; const newColor = nearestColor(oldR, oldG, oldB, palette); blockColors[y * width + x] = newColor; const errR = oldR - newColor.r; const errG = oldG - newColor.g; const errB = oldB - newColor.b; if (x + 1 < width) addError(x + 1, y, errR, errG, errB, 7 / 16); if (x - 1 >= 0 && y + 1 < height) addError(x - 1, y + 1, errR, errG, errB, 3 / 16); if (y + 1 < height) addError(x, y + 1, errR, errG, errB, 5 / 16); if (x + 1 < width && y + 1 < height) addError(x + 1, y + 1, errR, errG, errB, 1 / 16); } }

nearestColor的实现也需要稍微注意。最直接的是遍历调色板，计算 RGB 三个通道的欧氏距离。但欧氏距离在 RGB 空间并不完全代表人眼感知差异。一个比较省事的优化是给不同通道加权重，绿色通道权重大一点，因为人眼对绿色最敏感。artcraft 里用的是近似权重：红色 0.3、绿色 0.6、蓝色 0.1，效果比纯欧氏距离更自然。

抖动是个很神奇的东西，它不增加颜色数量，却能大幅提升画面的层次感。我通常在颜色数降到 16 或 8 时才打开抖动，颜色多反而会显得脏。这个参数最后也做成了滑杆：0 到 100 对应扩散强度的缩放。

3. 实操细节与参数调优

3.1 核心代码结构：一次渲染管线如何组织

artcraft 的前端结构并不复杂，本质是一条“加载图片 → 像素化 → 量化 → 抖动 → 绘制”的管线。我把它拆成了几个独立的纯函数，这样既方便逐个测试，也方便后续扩展。

整个处理最常用的入口是这样：

async function processImage(file: File, options: ProcessOptions) { const bitmap = await createImageBitmap(file); const resized = resizeImage(bitmap, options.maxOutputSize); const pixelData = getImageDataFromCanvas(resized); const blockColors = averageBlocks(pixelData, options.blockSize); const palette = quantize(blockColors, options.maxColors); const output = ditherAndMap(blockColors, palette, options.dither); return renderToCanvas(output, resized.width, resized.height, options.blockSize); }

createImageBitmap是浏览器里读取本地图片的高效方式，它能通过 Worker 解码图片，避免在主线程上等待太久。没有它的话，直接用new Image()加onload也可以，但解码可能在主线程卡顿，尤其遇到大图。

resizeImage这一步很关键。很多在线工具会忽略这一点，直接把原始分辨率塞进算法。但你要清楚：artcraft 输出的像素画，最终每个“像素块”在导出图上要占一个整数边长的方格。如果原图是 4000x3000，像素块大小是 8，那么生成的网格是 500x375，输出图分辨率是 4000x3000。如果像素块大小是 12，网格是 333x250，导出图是 3996x3000，差别不大。但网格数量乘以像素块大小后可能超出预计的内存，所以最好限制一下网格尺寸。比如我设定最大网格宽度为 800，如果原图是 4000 像素宽，像素块至少是 5，否则网格太多，处理和绘制都很慢。

3.2 参数怎么调才好看

“好看”是没有标准的，但我在多次测试中积累了一些经验，直接写出来供参考。

第一个参数是blockSize，也就是像素格子大小。头像、图标这类小图，我建议 6 到 12；大场景插画或者海报，可以放到 20 到 30。有人喜欢用超大像素做出完全“方块化”的抽象效果，那就可以调到 40 以上。多加一个参数“对齐边缘”也很好用，它会强制输出图的宽高是 blockSize 的整数倍，这样导出之后不会出现边缘半块像素。

第二个参数是maxColors，默认 16。如果你想要更接近照片但带一点像素感，选 32 或 48；如果想要极致的 8-bit 风格，8 甚至 4 都很刺激，但一定配合抖动打开。颜色数少但抖动开，会有点像旧杂志印刷的网点效果，这是 artcraft 我最喜欢的模式。

第三个参数是dither强度。我的建议是：颜色数小于等于 16 时，dither 设为 0.6 到 0.8；颜色数大于 32 时，可以直接关掉。抖动算法会把误差传播到附近像素，如果颜色数本来就多，再叠加抖动会显得画面很“脏”，像蒙了一层噪点。调试时可以先把 blockSize 定好，然后调整颜色数，最后才碰抖动，不要三个参数一起乱调。

还有一个容易被忽略的参数是“亮度校正”。很多图片在处理后会比原图略暗，就是因为平均值在线性空间和 sRGB 空间的差异。artcraft 默认开启 gamma 校正，如果你发现输出偏亮或偏暗，可以手动调整这个开关加一个简单的亮度偏移值，范围在 -50 到 50 之间。

3.3 导出与性能优化：别让浏览器卡死在计算上

artcraft 的 UI 是三个滑杆加一个预览区域，用户拖动滑杆时会触发实时重绘。这本身就隐藏着性能问题：每改一个参数，就要重新跑一遍完整的管线，如果是大图还会明显延迟。我做了三个优化。

第一是“参数防抖”。滑杆拖动会连续触发 onChange，如果每次触发都全量处理，性能再好的机器也会掉帧。我加了一个 200ms 的防抖：只有用户停止拖动后才会重新计算。这个延迟对于预览来说是完全可以接受的。

第二是“缩小预览”。实时预览时，先把原始图片压缩到一个较小的尺寸（比如最长边 480px），在预览 canvas 上处理；导出时才用原始尺寸或者用户设定的输出尺寸重新跑一遍。这样拖动滑杆时体验很流畅，最终效果又不受影响。很多人会忽略这个细节，直接用原始图实时处理，结果自然卡到爆。

第三是“使用 OffscreenCanvas 做中间缓存”。在把 ImageData 绘制到 canvas 之前，我会先在一个离屏 canvas 上完成全部像素操作，然后再一次性绘制到当前预览 canvas。直接在当前 canvas 上反复putImageData会触发主循环重绘，交互时容易闪烁。用离屏 canvas 作为缓冲，可以减少不必要的重绘。

const offscreen = new OffscreenCanvas(gridWidth, gridHeight); const ctx = offscreen.getContext('2d', { willReadFrequently: true }); ctx.putImageData(processedImageData, 0, 0); // 最后把 offscreen 绘制到预览 canvas mainCtx.imageSmoothingEnabled = false; mainCtx.drawImage(offscreen, 0, 0, previewWidth, previewHeight);

这里的imageSmoothingEnabled = false很重要，如果不关，浏览器会把像素块当成普通图像做双线性插值，边缘会模糊，像素风就毁掉了。

导出部分，我用的是把最终网格画到另一个大尺寸 canvas，然后canvas.toBlob得到 PNG。导出时注意：如果输出网格非常大（比如 800x600），那么最终 canvas 是 800blockSize 乘以 600blockSize，如果 blockSize 调得很大，比如 32，那输出图就是 25600x19200，像素容量接近 5 亿，浏览器直接内存溢出。所以我在输出逻辑里加了一个限制：输出图最大边限定 8192，超了就自动降低 blockSize，并弹提示。

4. 常见问题与排查实录

4.1 输出总是偏暗，怎么解决

这是我收到的第一条反馈：明明原图很亮，像素化之后整体暗了一截。原因前面提过，我们在 sRGB 空间直接做平均和量化，但 sRGB 本身是经过 gamma 编码的非线性色彩空间。两个较暗的像素平均出来的值，在线性光强上并不等于视觉上的中值，这会导致平均后的像素向暗端偏移。

解决的方法是引入颜色空间转换。最方便的做法是在平均像素块之前，先把每个像素的 RGB 值转成线性值，按线性值求平均，再转回 sRGB。这样处理不一定能消除全部色差，但肉眼可见地更接近原图。如果你不想做复杂转换，也可以简单地用“平方平均”代替“算术平均”，效果接近，只是不够精确。

我在 artcraft 里实现的是完整转换，因为代码很简单，而且现在的电脑运算能力完全扛得住。注意转换操作要放在像素化的平均步骤里，而不是放在量化之后，否则两种颜色误差在混合时会互相影响。

4.2 透明背景被填成了黑色或者白色

很多 PNG 图片带有透明通道，直接读取ImageData时，透明区域的 RGB 值可能是 0 也可能是上一次绘制的残留值，具体取决于 canvas 的初始化。如果不处理 alpha 通道，像素化之后这些区域就会被算成黑色，导致黑色背景糊在图上。

正确的做法是在读取像素之前，先把图像合成到一个统一背景色上，比如白色或你指定的颜色。最简单的实现是在一个离屏 canvas 上先填充背景色，再把图片绘制上去，最后getImageData，这样透明区域就会变成你设定的背景色。

ctx.fillStyle = '#ffffff'; ctx.fillRect(0, 0, width, height); ctx.drawImage(img, 0, 0); const data = ctx.getImageData(0, 0, width, height).data;

如果想保留透明背景，也可以在像素化步骤中单独处理 alpha。比如当某个像素块的 alpha 均值低于 255 时，强制输出为完全透明。但这会引入一个变数：透明像素和彩色像素之间的边界容易出现白边。我的建议是，默认不保留透明，而是用背景色替代，这样视觉效果可控，导出时也不用担心设备不支持 alpha。

4.3 大图处理卡顿、内存溢出

在开发早期，artcraft 处理一张 6000x4000 的照片时，页面直接卡死。原因是我把原图完整加载到 canvas，然后又建了一个同样尺寸的ImageData，内存占用瞬间飙到几个 GB。要知道每个像素需要 4 字节，6000x4000 就是 96MB，再创建几个临时数组，加上调色板排序，内存压力非常大。

解决的办法有三层：

一是限制输入尺寸。用户选择图片后，如果naturalWidth大于一个阈值（我设 2500），就先通过 canvas 等比缩放。这个操作对像素化结果几乎没影响，因为反正后面要被“像素化”，高分辨率信息本来就多余。

二是分块处理。对于特别大的网格，把整张图切成几个横向条带，逐条处理完再拼起来，避免同时创建超大数组。分块还能配合 Web Worker，我在 artcraft 里没有做多 Worker 分片，因为单线程处理 2500 内的图片已经足够快，但如果你想支持更大的图，分块是一个必然方向。

三是优化中间数据结构。不要用普通Array存储颜色，直接用Uint8Array或者复用已有数组，减少垃圾回收压力。我一开始为了代码可读性用了对象数组，性能测试后发现处理 60 万个像素点用了约 400ms，改用 Uint8Array 后降到 120ms，差距还是明显的。

5. 后续扩展与经验收尾

5.1 这些坑都踩完以后，artcraft 还能怎么玩

artcraft 目前是一个纯前端单页工具，但它的核心处理函数和 UI 是解耦的，所以做扩展很方便。比如你可以把它包装成一个命令行工具，输入一张图片加几个参数，输出一张像素图；也可以把它做成浏览器插件，在选中任意网页图片后一键转换；甚至可以把它接入一套批量处理脚本，给一组图片统一加像素风，用于公众号封面或游戏素材预览。

我打算下一步做的是：加入“调色板预设”功能。因为很多用户想要的不只是“自动量化出 N 种颜色”，而是希望限定到某个特定的复古风格调色板，比如 GB 的 4 色灰阶或者红白机的经典配色。实现上也很简单：预设就是一份硬编码的调色板数组，nearestColor函数直接查表，不再做中位切分。

另外还有人建议加上 GIF 导出，做逐帧像素动画。这会牵扯到编码 GIF 的库，目前我不打算手写，可能会引入一个维护良好的打包库。核心算法部分仍然保持手写，因为这才是 artcraft 的乐趣所在。

5.2 我个人踩坑后的三点体会

第一个体会是：不要迷信“看起来专业”的现成库。手写一遍像素化、量化、抖动算法，加起来没超过三百行代码，但我把它们理解得透透彻彻。遇到问题看自己的代码，一下就能定位；如果直接用库，遇到颜色偏暗，可能去翻文档找半天，还是一头雾水。

第二个体会是：交互设计对这类工具的重要性超乎想象。单纯把算法跑通很容易，但“拖动滑杆就能看效果”这个体验才是让用户留下来的关键。为了这个体验，防抖、离屏画布、预览尺寸这些工程细节，往往比算法本身更费心思。我花了大量时间调 UI 的响应速度，最终效果也直观反映在大家的使用评价上。

第三个体会是：颜色管理别偷懒。早年我用一张深色照片测试，怎么调都感觉颜色“发闷”，后来才意识到是没做 gamma 校正。对于任何和色彩打交道的项目，哪怕只是做一个娱乐性质的小工具，先搞清楚工作色彩空间，能少走很多弯路。

artcraft 这个项目本身不算大，但麻雀虽小五脏俱全。从图像像素化、颜色量化到抖动扩散，再到性能优化和浏览器兼容，每个环节都有值得说道的细节。如果你也在折腾类似的创意编码工具，希望这篇分享能给你一点启发。有更好的想法和实现方式，欢迎评论区聊聊。