图片工具看起来只是把文件放进画布，再导出一个文件，但真正稳定的实现需要同时处理格式兼容、内存管理、交互响应和算法执行。LemonArt 采用 Vue 3 + TypeScript 组织界面状态，用 Canvas 负责预览和绘制，用 OpenCV.js 负责计算密集型图像算法，最终仍在浏览器本地完成处理。
一、把图片处理拆成四层
LemonArt 没有把所有逻辑写进组件事件，而是把工作流拆成输入层、预览层、算法层和输出层。输入层负责 File、Object URL 与基础校验；预览层维护裁剪框、缩放比例、旋转角度和调色参数；算法层按需调用 OpenCV.js；输出层将最终像素交给浏览器原生编码或项目内置编码器。
这种分层的好处是交互状态不会和具体编码格式绑死。用户可以先裁剪、旋转和去噪，最后再选择 PNG、JPG、WebP 或其他输出格式。
- 输入层：拖放上传、批量文件列表、文件大小和格式识别。
- 预览层：Canvas 实时绘制，裁剪框支持移动、边缘调整和八方向控制点。
- 算法层：OpenCV.js 执行去噪、阈值、形态学、背景移除与修复。
- 输出层：根据 MIME 能力选择原生编码或项目编码器，并生成可下载 Blob。
二、为什么 Canvas 适合做实时预览
Canvas 是浏览器中最直接的像素渲染目标。图片加载后，LemonArt 会根据当前裁剪区域和变换参数创建绘制上下文，再把亮度、对比度、饱和度和灰度效果组合成一条可重复执行的预览管线。每次参数变化只更新预览，不修改用户原始 File，因此重置操作可以恢复到最初状态。
裁剪编辑的关键不是把 DOM 图片移动到某个位置，而是把屏幕坐标转换为原始像素坐标。编辑器会根据 Canvas 的实际显示尺寸计算比例，拖动边缘时同步限制最小宽高和图像边界，避免高 DPI 屏幕或响应式布局导致导出尺寸错误。
const scaleX = image.naturalWidth / canvasRect.width
const sourceX = (pointerX - canvasRect.left) * scaleX
const sourceY = (pointerY - canvasRect.top) * scaleY
ctx.drawImage(image, cropX, cropY, cropWidth, cropHeight, 0, 0, outWidth, outHeight)ts三、OpenCV.js 如何进入处理管线
OpenCV.js 适合处理需要矩阵运算的任务。LemonArt 将 Canvas 像素读入 cv.Mat，在算法完成后把结果写回 Canvas，并且在每次处理结束时显式 delete Mat、mask 和临时对象。这样既能利用 OpenCV 的成熟算法，也能避免长时间编辑大图时 WebAssembly 堆持续增长。
图像修复尤其依赖这条管线：用户在 Canvas 上涂抹遮罩，程序把遮罩转换为单通道矩阵，再调用 cv.inpaint。Telea 适合快速补全，Navier-Stokes 在结构连续的场景中可能更自然，最终结果仍可回到同一个编辑预览和导出流程。
值得注意的细节是通道一致性：OpenCV 的 inpaint 只接受三通道 BGR/RGB 输入，而 Canvas 像素是 RGBA，因此修复前后都要做颜色空间转换——进入时把 RGBA 转 RGB，遮罩转灰度并二值化，完成后把结果恢复成 RGBA，否则带透明通道的图片在导出时会出现颜色错位。
if (sourceChannels === 4) cv.cvtColor(current, rgb, cv.COLOR_RGBA2RGB)
cv.cvtColor(maskSource, maskGray, cv.COLOR_RGBA2GRAY)
cv.threshold(maskGray, maskBinary, 1, 255, cv.THRESH_BINARY)
cv.inpaint(rgb, maskBinary, repaired, radius, cv.INPAINT_TELEA)
cv.cvtColor(repaired, restored, cv.COLOR_RGB2RGBA)ts四、响应速度来自状态控制，而不是减少功能
图片编辑器的卡顿通常来自重复创建 Image、重复加载 OpenCV 或在每个 pointermove 中进行昂贵编码。LemonArt 将预览绘制放进 requestAnimationFrame，同一帧内的多次参数变化只执行一次绘制；OpenCV.js 运行时按需加载并缓存；编码只发生在用户点击导出时。
对于生产环境，算法状态和界面状态也要分开。加载状态、导出状态、修复遮罩状态分别维护，按钮只在对应条件满足时启用，用户可以清楚知道当前是正在载入、预览还是导出。
五、主题与响应式：界面状态同样需要分层
暗色模式不是简单的换背景色。LemonArt 用 CSS 变量定义完整调色板（--bg-shell、--text-primary、--accent、--border-light 等），主题切换只是切换根节点上的变量集合，组件样式完全不感知具体颜色，因此不会出现“某个面板忘了适配暗色”的问题。主题支持 light / dark / system 三种模式，system 跟随 prefers-color-scheme，用户选择持久化到 localStorage，并在首屏内联脚本中提前应用，避免页面闪烁。
移动端适配依赖同样的分层思路。导航在窄屏下隐藏桌面链接，改为汉堡菜单配合浮层导航，通过遮罩点击或 Esc 键关闭，并维护 aria-expanded 状态；编辑器的侧边文件列表改为横向滚动，控制面板的按钮网格从四列收缩为两列，触控目标放大到适合手指操作的尺寸。响应式不是复制一套移动端代码，而是让同一份状态在断点处调整布局与交互方式。
- 主题变量与组件样式解耦，暗色模式不需要条件样式或重复覆盖。
- system 模式通过 prefers-color-scheme 媒体查询实现，用户手动选择优先。
- 移动端菜单用 aria-expanded 与遮罩管理展开状态，Esc 与点击外部均可关闭。
- 编辑面板在窄屏下切换为横向滚动与更大的触控区域，保持触屏可用性。
六、状态机与反馈：按钮、进度与可访问性
图片工具的大部分“卡住”问题，其实不是算法慢，而是界面没有表达状态。LemonArt 把处理状态拆成三个独立的布尔量：isConverting（批量转换中）、editLoading（编辑器正在读取图片）、isExportingEdit（正在导出编辑结果），每个状态都精确对应一组按钮的 disabled 与 loading 文案，用户不会看到“点了没反应”的场景。
进度与错误信息通过统一的 notice 通道输出，并放在 aria-live 区域内，屏幕阅读器也能感知状态变化。逐文件进度以百分比显示在每一行的状态位，失败的条目单独标红并给出原因，不会把整批任务打成失败。
- 每个异步流程拥有独立的 loading 状态，避免用一个全局 spinner 掩盖所有问题。
- notice 使用 aria-live 区域播报，键盘和读屏用户能获得同样的反馈。
- 逐文件状态（waiting / converting / done / error）与下载按钮联动。
- 失败单行展示错误原因，重试或继续处理其余文件都保持可用。
七、这套架构适合继续扩展什么
分层后，增加功能不需要重新设计整个页面。例如可以在 OpenCV 管线中加入边缘检测、透视校正和颜色空间转换，在输出层加入更多无损格式，在博客和帮助页面中解释每个算法的使用边界。对前端项目来说，稳定的边界比堆叠更多按钮更重要。
要点总结
- Canvas 负责交互和预览，OpenCV.js 负责矩阵算法。
- 所有处理都围绕原始像素坐标计算，避免响应式布局造成导出偏差。
- requestAnimationFrame、运行时缓存和显式释放是大图编辑流畅度的基础。
- 颜色空间转换（RGBA ↔ RGB）与 Mat 生命周期是算法管线的两个最容易出错的细节。
- 状态机与 aria-live 反馈让复杂流程在慢设备上依然可理解、可操作。