企业官网建设流程全解析

1. 这不是又一个“拖拽式”编辑器：Wan2GP 图像编辑器到底在解决什么真问题？

你有没有遇到过这样的场景：在做一个轻量级图像处理需求时，团队里前端同学说“用 Fabric.js 吧，成熟稳定”，后端同事却皱眉：“但我们要加 AI 去噪模块，Fabric 的渲染管线太深，插不进自定义 WebGL 计算节点”；设计师提了个新需求——“希望用户能一边调色一边实时预览 LUT 叠加效果，且支持导出带 Alpha 的 PNG 序列”，结果发现现有编辑器的图层系统是纯 CPU 拼合的，一开预览就卡顿掉帧；更头疼的是，当产品要快速上线一个“老照片修复”小功能时，开发得从头搭状态管理、图层树、撤销栈、画布缩放逻辑……整整两周，只为了加一个滤镜按钮。

Wan2GP 图像编辑器就是为这类“夹缝需求”而生的。它不追求 Photoshop 级的全能，也不满足于 Canva 风格的模板化——它的核心定位非常明确：为需要深度定制图像处理能力的中型 Web 应用，提供可拆解、可替换、可热插拔的编辑器内核。关键词“Wan2GP”本身就有暗示：“Wan”代表 Web 全平台适配（响应式、PWA、离线缓存），“2G”指代双图形后端（2D Canvas + GPU 加速 WebGL），而“P”则是 Pipeline（处理流水线）的缩写。整套架构围绕三个刚性约束展开：第一，渲染必须可降级——低端设备自动切回 Canvas2D，高端设备无缝启用 PIXI.js 的 WebGL 渲染器；第二，逻辑必须可隔离——图层管理、历史记录、工具交互、滤镜计算这四块核心能力，彼此不耦合，改一个不影响其余；第三，扩展必须零编译——新增一个“风格迁移”工具，只需写一个 Svelte 组件 + 一个 WebGL Shader 文件，注册进插件系统即可生效，无需动主工程代码。

我参与过两个真实项目验证这套设计：一个是某高校数字人文实验室的古籍图像标注平台，他们需要把传统 OCR 标注框和基于 U-Net 的语义分割掩码叠加在同一画布上，且要求标注框能被 SVG 矢量缩放而不失真，而分割结果必须用 WebGL 实时渲染（因需叠加多层热力图）；另一个是某电商后台的商品图智能抠图模块，运营人员要能手动微调 AI 生成的蒙版边缘，这就要求画布同时支持像素级笔刷（Canvas2D）和矢量贝塞尔曲线（SVG 路径）。Wan2GP 的模块化设计让这两个截然不同的需求，共享了同一套图层树、撤销栈和坐标系管理，仅替换了各自的渲染器和工具集。这种“一套骨架、多套血肉”的能力，正是它区别于市面上绝大多数图像编辑器的本质特征。

2. 架构选型背后的硬核权衡：为什么是 PIXI.js + Svelte，而不是 Three.js + React？

很多人看到“WebGL 图像编辑器”，第一反应是 Three.js。但 Wan2GP 团队在技术预研阶段花了整整六周做对比实验，最终放弃 Three.js 选择 PIXI.js，这个决定背后有三重不可妥协的硬约束。

首先是像素精度控制。Three.js 的核心抽象是“3D 场景”，所有 2D 内容都需包裹在正交相机下的平面网格中。这意味着当你想对一张 1920×1080 的图片做逐像素操作（比如实现一个“仿制图章”工具），Three.js 会强制你将图像作为纹理贴到一个面片上，而面片顶点坐标映射到屏幕像素时，存在浮点数舍入误差。我们实测过：在 100% 缩放下，Three.js 渲染的图像边缘会出现 0.5px 的模糊或错位，这对需要像素级对齐的修图操作是致命的。而 PIXI.js 本质是“2D 渲染引擎”，其PIXI.Sprite的x/y坐标直接对应 CSS 像素，scale属性精确控制纹理采样，配合roundPixels: true选项，能确保 1:1 映射无偏差。这个细节看似微小，但在“放大 400% 精修睫毛”这类场景中，就是专业与业余的分水岭。

其次是渲染管线可插拔性。Three.js 的渲染流程是黑盒化的：renderer.render(scene, camera)一步到位，你想在纹理采样前插入自定义 GLSL 代码？得重写ShaderMaterial并绕过内置光照系统，复杂度陡增。而 PIXI.js 的Filter系统是为图像处理量身定制的：每个 Filter 就是一个独立的 WebGL 程序，可链式组合（如blurFilter → colorMatrixFilter → noiseFilter），且支持运行时动态添加/移除。Wan2GP 的“实时滤镜预览”功能，就是靠 PIXI.js 的 Filter 管线实现的——用户拖动色相滑块时，系统不是重新渲染整个图层，而是仅更新ColorMatrixFilter的 uniform 参数，GPU 端毫秒级响应。这种细粒度控制，是 Three.js 的通用渲染器无法提供的。

最后是包体积与启动性能。Three.js 完整版压缩后约 280KB，而 PIXI.js v7 的核心包（@pixi/core+@pixi/sprite）仅 65KB。更重要的是，Three.js 的初始化依赖大量 WebGL 上下文检测和兼容性补丁，冷启动耗时平均 120ms；PIXI.js 的Application初始化在现代浏览器中稳定控制在 35ms 内。对于 Wan2GP 这类可能嵌入到 CMS 后台或小程序 WebView 中的轻量编辑器，首屏可交互时间（TTI）每减少 50ms，用户留存率就提升 1.2%——这个数据来自我们 A/B 测试的真实埋点。

至于 Svelte 的选择，则是对 React/Vue 生态的一次主动“减法”。React 的虚拟 DOM 差异算法虽强大，但图像编辑器的核心状态（图层位置、缩放比例、当前工具、滤镜参数）是高频更新的（鼠标移动时每秒触发 60+ 次 state 更新）。React 的 reconciler 在每次更新时都要遍历整个 VDOM 树，即使只改了一个scale值，也会触发无关组件的 re-render。Svelte 的编译时响应式则完全不同：它在构建阶段就分析出scale只影响画布容器的transform样式，因此运行时只更新那一行 CSS，零虚拟 DOM 开销。我们用 Chrome Performance 面板对比过：同等操作下，Svelte 版本的主线程 JS 执行时间比 React 版低 68%，尤其在低端安卓机上，帧率从 32fps 提升至稳定的 58fps。

提示：不要被“Svelte 更轻量”的表象迷惑。真正关键的是它的响应式粒度——图像编辑器里，一个图层的opacity变化，不该触发整个工具栏的重绘；一个滤镜的contrast参数变动，不该导致图层面板的 DOM 重建。Svelte 的$:声明式响应式，天然契合这种“状态-视图”的精准映射关系。

3. 模块化设计的四大支柱：图层系统、渲染引擎、工具链、状态管理如何解耦？

Wan2GP 的模块化不是口号，而是通过四个严格隔离的子系统实现的，每个系统都有清晰的接口契约和独立的生命周期。它们之间不直接 import 彼此的实现，只通过事件总线（EventBus）和共享状态池（Store）通信。这种设计让团队能并行开发：A 同学优化 WebGL 滤镜性能，B 同学重构图层拖拽逻辑，C 同学开发新笔刷工具，互不阻塞。

3.1 图层系统（Layer System）：不只是“堆叠顺序”，而是可编程的图像容器

传统编辑器的图层常被简化为一个数组，layers[0]是背景，layers[1]是人物……但 Wan2GP 的图层是具备完整行为能力的对象。每个图层实例必须实现ILayer接口：

interface ILayer { id: string; name: string; visible: boolean; locked: boolean; opacity: number; blendMode: BlendMode; // normal, multiply, screen... bounds: Rectangle; // 世界坐标系下的包围盒 getTexture(): PIXI.Texture | null; // 返回当前图层的渲染源 applyTransform(matrix: PIXI.Matrix): void; // 应用矩阵变换（缩放/旋转/平移） toDataUrl(format?: 'png' | 'jpg'): Promise<string>; // 导出为 Data URL }

关键创新在于getTexture()方法。它不返回原始图片，而是返回一个 PIXI.Texture 对象——这个对象可能是：

• 一张加载完成的ImageBitmap（用于普通图层）；
• 一个PIXI.RenderTexture（用于含滤镜的图层，其内容是 WebGL 渲染结果）；
• 甚至是一个PIXI.Graphics的generateTexture()输出（用于矢量图层，如路径描边）。

这种设计让“混合模式”（Blend Mode）的实现变得极其优雅：PIXI.js 原生支持Sprite.blendMode，但仅限于 Sprite 与父容器之间的混合。Wan2GP 则通过PIXI.RenderTexture将每个图层渲染到独立纹理，再将这些纹理按图层顺序依次绘制到主画布上，并在绘制时指定PIXI.BLEND_MODES.MULTIPLY等模式。这样，用户看到的“图层混合效果”，其实是 GPU 端真正的像素级混合运算，而非 CPU 拼合的近似值。

图层系统的另一大特性是惰性渲染（Lazy Rendering）。当图层被隐藏（visible = false）或完全移出视口时，其关联的RenderTexture不会被更新，内存占用直降 40%。我们曾测试过 50 个图层的极端场景：开启惰性渲染后，内存峰值从 1.2GB 降至 720MB，且切换图层可见性时无卡顿。

3.2 渲染引擎（Rendering Engine）：双后端无缝切换的底层机制

渲染引擎是 Wan2GP 的“肌肉”，它必须同时满足两个看似矛盾的需求：极致性能（GPU 加速）和极致兼容（老旧设备降级）。其核心是RendererAdapter抽象层：

abstract class RendererAdapter { abstract init(canvas: HTMLCanvasElement): Promise<void>; abstract render(layers: ILayer[]): void; abstract resize(width: number, height: number): void; abstract destroy(): void; } class WebGLRenderer extends RendererAdapter { /* 基于 PIXI.Application */ } class Canvas2DRenderer extends RendererAdapter { /* 基于 CanvasRenderingContext2D */ }

切换逻辑藏在RendererFactory中：

class RendererFactory { static create(canvas: HTMLCanvasElement): RendererAdapter { // 检测 WebGL 支持度与性能 const gl = canvas.getContext('webgl') || canvas.getContext('webgl2'); if (gl && this.isWebGLPerformant(gl)) { return new WebGLRenderer(); } else { return new Canvas2DRenderer(); } } private static isWebGLPerformant(gl: WebGLRenderingContext | WebGL2RenderingContext): boolean { // 关键指标：是否支持浮点纹理（用于高精度滤镜） const ext = gl.getExtension('OES_texture_float'); // 是否支持帧缓冲对象（用于 RenderTexture） const fboExt = gl.getExtension('WEBGL_framebuffer_object'); // 设备内存是否充足（通过 navigator.deviceMemory 估算） return !!ext && !!fboExt && (navigator.deviceMemory || 4) >= 4; } }

这个设计的价值在真实场景中凸显：某教育平台将 Wan2GP 集成到在线课堂白板中，学生用 iPad Air 2（iOS 12）上课时，自动降级为 Canvas2D 模式，基础涂鸦流畅；而教师端用 M1 Mac，无缝启用 WebGL，实时播放 4K 视频滤镜特效。更妙的是，降级过程对上层业务代码完全透明——图层系统、工具链、状态管理均无需感知渲染后端差异，它们只调用renderer.render(layers)这一个方法。

3.3 工具链（Toolchain）：从“橡皮擦”到“AI 修复”的统一接入协议

工具在 Wan2GP 中不是简单的按钮点击事件，而是一套完整的生命周期管理对象。每个工具必须实现ITool接口：

interface ITool { id: string; name: string; icon: string; // SVG 字符串 activate(): void; // 工具被选中时调用 deactivate(): void; // 工具被取消时调用 onMouseDown(e: PointerEvent): void; onMouseMove(e: PointerEvent): void; onMouseUp(e: PointerEvent): void; onWheel(e: WheelEvent): void; onKeyDown(e: KeyboardEvent): void; renderOverlay(renderer: PIXI.Renderer): void; // 渲染辅助图形（如橡皮擦的虚线圆圈） }

这个设计让“AI 工具”能与传统工具平起平坐。例如“老照片修复”工具：

• activate()时，加载 WASM 编译的 OpenCV 模块（约 1.2MB），并预热模型；
• onMouseDown()获取当前图层的base64数据，发送给 Web Worker 处理；
• renderOverlay()在画布上绘制一个半透明的“修复区域”蒙版，提示用户涂抹范围；
• onMouseMove()实时更新蒙版位置，不触发主渲染循环。

所有工具共享同一套输入事件处理管道，避免了 React/Vue 中常见的“事件监听器冲突”问题（比如画布缩放工具和画笔工具同时监听wheel事件）。工具链还内置了快捷键路由系统：按下B切换画笔，E切换橡皮擦，Ctrl+Z触发全局撤销——这些快捷键绑定由ToolManager统一管理，工具自身只需声明shortcuts: ['b', 'e']，无需关心 DOM 事件监听细节。

3.4 状态管理（State Management）：为什么不用 Redux 或 Zustand？

Wan2GP 的状态管理采用极简的WritableStore模式，核心只有三个 API：

// store.ts export const editorStore = writable<EditorState>({ layers: [], activeTool: 'select', zoom: 1, pan: { x: 0, y: 0 }, history: { undoStack: [], redoStack: [] } }); // 在 Svelte 组件中使用 $: $editorStore.layers; // 自动订阅 editorStore.update(state => ({ ...state, zoom: state.zoom * 1.2 })); // 更新

放弃 Redux 的根本原因在于：图像编辑器的状态变更具有强时空局部性。用户调整一个图层的透明度，只会影响该图层的渲染，不会波及工具栏或历史面板；用户缩放画布，只改变zoom和pan，与图层数据完全无关。Redux 的“单一状态树”和“reducer 纯函数”在此场景下反而成了负担——每次dispatch({ type: 'UPDATE_LAYER_OPACITY', payload: { id: 'l1', opacity: 0.7 } })，都要遍历整个状态树做深拷贝，而实际变更的只是layers.find(l => l.id === 'l1').opacity这一个字段。

Wan2GP 的writableStore 直接暴露响应式变量，Svelte 编译器在构建时就能分析出zoom只被画布容器组件消费，因此editorStore.update()调用时，只通知该组件重渲染，其他组件（如图层面板、滤镜面板）完全不受影响。我们在 100 层图层的压测中对比过：Redux 版本的update耗时 42ms，而 Svelte Store 版本仅 3.1ms，差距达 13 倍。

注意：writable并非万能。对于需要跨组件共享的复杂状态（如“当前正在执行的异步任务列表”），Wan2GP 采用ReadableStore+derived组合：const activeTasks = derived([taskStore], ([$tasks]) => $tasks.filter(t => t.status === 'running'))。这种“按需派生”的方式，比 Redux 的 selector 更轻量，且无缓存失效风险。

4. 实操落地：从零搭建一个可运行的 Wan2GP 编辑器核心

现在我们动手搭建一个最小可行版本（MVP），它包含：可缩放/平移的画布、一个图层、一个画笔工具、一个基础滤镜面板。整个过程不依赖任何 CLI 脚手架，全部手动配置，让你看清每一处关键决策。

4.1 环境初始化与依赖安装

首先创建项目结构：

mkdir wan2gp-mvp && cd wan2gp-mvp npm init -y npm install pixi.js svelte@4 svelte-preprocess typescript @tsconfig/svelte npm install -D rollup @rollup/plugin-node-resolve @rollup/plugin-commonjs @rollup/plugin-typescript rollup-plugin-svelte

关键点解析：

• PIXI.js 选择 v7：v7 是首个原生支持 TypeScript 的大版本，且移除了对@pixi/graphics-extras等冗余包的依赖，核心包更精简；
• Svelte 4：相比 Svelte 5（当时尚未正式发布），Svelte 4 的生态系统更成熟，svelte-preprocess对 TypeScript 的支持更稳定；
• Rollup 而非 Vite：Vite 的 HMR（热模块替换）在 PIXI.js 场景下有兼容性问题——当PIXI.Application实例被 HMR 替换时，WebGL 上下文会丢失，导致画布变黑。Rollup 的--watch模式虽慢 2 秒，但能保证 WebGL 上下文稳定。

4.2 核心渲染器实现：WebGL 与 Canvas2D 的双后端

创建src/lib/renderer/RendererAdapter.ts：

import * as PIXI from 'pixi.js'; export abstract class RendererAdapter { protected app: PIXI.Application | null = null; protected canvas: HTMLCanvasElement | null = null; abstract init(canvas: HTMLCanvasElement): Promise<void>; abstract render(layers: any[]): void; abstract resize(width: number, height: number): void; abstract destroy(): void; } // src/lib/renderer/WebGLRenderer.ts export class WebGLRenderer extends RendererAdapter { async init(canvas: HTMLCanvasElement): Promise<void> { this.canvas = canvas; // 关键配置：禁用 PIXI 默认的抗锯齿（影响像素精度） this.app = new PIXI.Application({ view: canvas, antialias: false, autoDensity: true, resolution: window.devicePixelRatio || 1, backgroundColor: 0xffffff, powerPreference: 'high-performance' }); // 禁用 PIXI 的自动 resize，由我们手动控制 this.app.renderer.view.style.width = '100%'; this.app.renderer.view.style.height = '100%'; } render(layers: any[]): void { if (!this.app) return; // 清空舞台 this.app.stage.removeChildren(); // 将图层渲染到舞台（此处简化，实际需遍历 layers） layers.forEach((layer: any) => { if (layer.sprite) { this.app.stage.addChild(layer.sprite); } }); } resize(width: number, height: number): void { if (!this.app) return; this.app.renderer.resize(width, height); } destroy(): void { if (this.app) { this.app.destroy(true, true); this.app = null; } } }

Canvas2DRenderer的实现更简单，但要注意一个坑：Canvas2D 的drawImage在缩放时默认使用双线性插值，会导致图像模糊。必须显式设置imageSmoothingEnabled = false：

// src/lib/renderer/Canvas2DRenderer.ts export class Canvas2DRenderer extends RendererAdapter { private ctx: CanvasRenderingContext2D | null = null; async init(canvas: HTMLCanvasElement): Promise<void> { this.canvas = canvas; this.ctx = canvas.getContext('2d'); if (!this.ctx) throw new Error('Canvas2D context not available'); // 关键！关闭抗锯齿，保证像素锐利 this.ctx.imageSmoothingEnabled = false; } render(layers: any[]): void { if (!this.ctx || !this.canvas) return; const { width, height } = this.canvas; this.ctx.clearRect(0, 0, width, height); layers.forEach((layer: any) => { if (layer.image) { this.ctx.drawImage( layer.image, 0, 0, layer.image.width, layer.image.height, 0, 0, width, height ); } }); } resize(width: number, height: number): void { if (!this.canvas) return; this.canvas.width = width; this.canvas.height = height; } destroy(): void { this.ctx = null; } }

4.3 图层与画布组件：Svelte 中的响应式集成

创建src/lib/components/Canvas.svelte：

<script lang="ts"> import { onMount, onDestroy } from 'svelte'; import { editorStore } from '$lib/stores/editorStore'; import { WebGLRenderer, Canvas2DRenderer } from '$lib/renderer/RendererAdapter'; let canvasRef: HTMLCanvasElement | null = null; let renderer: any = null; onMount(async () => { if (!canvasRef) return; // 根据设备能力选择渲染器 const gl = canvasRef.getContext('webgl'); if (gl) { renderer = new WebGLRenderer(); } else { renderer = new Canvas2DRenderer(); } await renderer.init(canvasRef); // 监听窗口大小变化 const handleResize = () => { if (canvasRef && renderer) { const rect = canvasRef.getBoundingClientRect(); renderer.resize(rect.width, rect.height); } }; window.addEventListener('resize', handleResize); handleResize(); // 初始化尺寸 // 渲染循环 const renderLoop = () => { if (renderer) { // 从 store 获取图层数据 const { layers } = $editorStore; renderer.render(layers); } requestAnimationFrame(renderLoop); }; renderLoop(); onDestroy(() => { window.removeEventListener('resize', handleResize); if (renderer) renderer.destroy(); }); }); </script> <canvas bind:this={canvasRef} class="w-full h-full bg-white" style="touch-action: none;" />

这个组件的关键在于：它不持有任何图层数据，只从editorStore订阅状态。当用户在图层面板中添加新图层时，editorStore.update()会触发Canvas.svelte的renderLoop重新获取layers数组并调用renderer.render()。这种“数据驱动渲染”的模式，彻底解耦了 UI 层与业务逻辑。

4.4 画笔工具实现：从鼠标事件到 WebGL 绘制

创建src/lib/tools/BrushTool.ts：

import * as PIXI from 'pixi.js'; export class BrushTool { private graphics: PIXI.Graphics | null = null; private isDrawing = false; private lastX = 0; private lastY = 0; constructor(private renderer: PIXI.Renderer) {} activate() { this.graphics = new PIXI.Graphics(); this.graphics.lineStyle(3, 0x000000, 1); } deactivate() { if (this.graphics) { this.graphics.clear(); this.graphics = null; } } onMouseDown(e: PointerEvent) { if (!this.graphics) return; this.isDrawing = true; const pos = this.getCanvasPosition(e); this.lastX = pos.x; this.lastY = pos.y; this.graphics.moveTo(pos.x, pos.y); } onMouseMove(e: PointerEvent) { if (!this.graphics || !this.isDrawing) return; const pos = this.getCanvasPosition(e); this.graphics.lineTo(pos.x, pos.y); this.lastX = pos.x; this.lastY = pos.y; } onMouseUp() { this.isDrawing = false; } // 将鼠标坐标转换为画布坐标（考虑缩放和平移） private getCanvasPosition(e: PointerEvent): { x: number; y: number } { if (!this.renderer.view) return { x: 0, y: 0 }; const rect = this.renderer.view.getBoundingClientRect(); const scaleX = this.renderer.view.width / rect.width; const scaleY = this.renderer.view.height / rect.height; return { x: (e.clientX - rect.left) * scaleX, y: (e.clientY - rect.top) * scaleY }; } // 渲染到画布（覆盖在图像之上） renderOverlay() { if (!this.graphics || !this.renderer) return; this.renderer.render(this.graphics); } }

注意getCanvasPosition方法：它不是简单地取e.offsetX/Y，而是根据renderer.view的实际尺寸与 DOM 元素尺寸的比例，进行精确换算。这是保证画笔轨迹与图像像素对齐的核心。我们曾踩过坑：直接用e.offsetX会导致在高 DPI 屏幕上画笔偏移 2px，因为offsetX返回的是 CSS 像素，而renderer.view使用的是设备像素。

4.5 滤镜面板：用 PIXI.Filter 实现实时预览

创建src/lib/components/FilterPanel.svelte：

<script lang="ts"> import { editorStore } from '$lib/stores/editorStore'; import * as PIXI from 'pixi.js'; let brightness = 0; let contrast = 1; let saturation = 1; $: if ($editorStore.layers.length > 0) { const layer = $editorStore.layers[0]; if (layer.sprite && layer.sprite.filters?.length) { const filter = layer.sprite.filters[0] as PIXI.ColorMatrixFilter; filter.brightness(brightness); filter.contrast(contrast); filter.saturation(saturation); } } </script> <div class="p-4 bg-gray-50 border rounded"> <h3 class="font-medium mb-3">基础调节</h3> <div class="space-y-4"> <div> <label class="block text-sm mb-1">亮度: {brightness}</label> <input type="range" min="-100" max="100" bind:value={brightness} class="w-full" /> </div> <div> <label class="block text-sm mb-1">对比度: {contrast.toFixed(2)}</label> <input type="range" min="0.1" max="3" step="0.01" bind:value={contrast} class="w-full" /> </div> </div> </div>

这里的关键是$:声明式响应式：当brightness值变化时，Svelte 会立即执行filter.brightness(brightness)，而 PIXI.js 的ColorMatrixFilter会将新值通过uniform传给 GPU，整个过程在 16ms 内完成，实现真正的实时预览。不需要任何debounce或throttle，因为 Svelte 的更新是同步且高效的。

5. 避坑指南：那些官方文档不会告诉你的 Wan2GP 实战经验

在多个项目中落地 Wan2GP 后，我们总结出一套“血泪教训清单”。这些不是理论推演，而是真金白银踩出来的坑，每一条都附带可复用的解决方案。

5.1 WebGL 内存泄漏：你以为的“销毁”可能只是假死

现象：在频繁切换图层、应用滤镜、缩放画布后，Chrome 任务管理器显示页面内存持续增长，最终崩溃。Performance 面板显示WebGLTexture对象数量不断上升。

根因：PIXI.js 的Texture.destroy()方法默认只释放 CPU 端引用，不主动调用gl.deleteTexture()。WebGL 纹理对象仍驻留在 GPU 显存中，直到浏览器垃圾回收器（GC）触发。而 GC 的时机不可控，尤其在长时间运行的编辑器中，GC 可能数分钟才发生一次。

解决方案：强制清理 WebGL 资源。在WebGLRenderer.destroy()中添加：

destroy(): void { if (!this.app) return; // 1. 销毁所有纹理 PIXI.TextureCache.forEach((texture: PIXI.Texture) => { if (texture.baseTexture && texture.baseTexture.resource) { texture.baseTexture.resource.destroy(); // 强制释放 WebGL 资源 } }); // 2. 销毁所有 RenderTexture PIXI.RenderTextureCache.forEach((rt: PIXI.RenderTexture) => { rt.destroy(true); // true 表示销毁底层 WebGLTexture }); // 3. 最后销毁 Application this.app.destroy(true, true); this.app = null; }

实测效果：内存泄漏周期从“必现于 5 分钟内”延长至“稳定运行 2 小时无泄漏”。关键在于resource.destroy()和rt.destroy(true)这两行。

5.2 Canvas2D 模式下的“画笔断线”：高 DPI 屏幕的陷阱

现象：在 MacBook Pro（Retina 屏）上使用画笔工具，鼠标快速移动时，画出的线条出现明显断点，像一串分离的圆点。

根因：Retina 屏幕的devicePixelRatio为 2，即 1 个 CSS 像素对应 2×2 个物理像素。Canvas2D 的lineWidth: 3在 CSS 像素下是 3px，但在设备像素下是 6px，而lineCap: 'round'的圆角半径计算未按设备像素校准，导致连接处断裂。

解决方案：动态适配lineWidth。在BrushTool的activate()方法中：

activate() { this.graphics = new PIXI.Graphics(); // 根据 devicePixelRatio 动态设置线宽 const dpr = window.devicePixelRatio || 1; this.graphics.lineStyle(3 * dpr, 0x000000, 1); this.graphics.lineCap = 'round'; this.graphics.lineJoin = 'round'; }

同时，在Canvas.svelte的handleResize中，必须按 DPR 设置 canvas 的width/height：

const handleResize = () => { if (!canvasRef) return; const rect = canvasRef.getBoundingClientRect(); const dpr = window.devicePixelRatio || 1; canvasRef.width = rect.width * dpr; canvasRef.height = rect.height * dpr; canvasRef.style.width = `${rect.width}px`; canvasRef.style.height = `${rect.height}px`; // ... 其他 resize 逻辑 };

5.3 滤镜参数的“数值漂移”：浮点数精度灾难

现象：用户将亮度滑块从 0 拖到 50 再拖回 0，图像并未恢复原始状态，而是略微变暗。反复拖动后，偏差累积。

根因：PIXI.js 的ColorMatrixFilter.brightness()方法内部使用Math.pow(2, value / 100)计算亮度系数，而value / 100是浮点数除法，存在 IEEE 754 精度误差。连续多次pow运算后，误差被放大。

解决方案：不依赖 Filter 的链式方法，改为直接操作uniform。创建一个PreciseBrightnessFilter：

import * as PIXI from 'pixi.js'; export class PreciseBrightnessFilter extends PIXI.Filter { constructor() { super( // vertex shader `attribute vec2 aVertexPosition; attribute vec2 aTextureCoord; uniform mat4 uProjectionMatrix; uniform mat4 uModelViewMatrix; varying vec2 vTextureCoord; void main() { gl_Position = uProjectionMatrix * uModelViewMatrix * vec4(aVertexPosition, 0.0, 1.0); vTextureCoord = aTextureCoord; }`, // fragment shader `varying vec2 vTextureCoord; uniform sampler2D uSampler; uniform float uBrightness; void main() { vec4 color = texture2D(uSampler, vTextureCoord); // 使用线性公式，避免 pow 精度损失 float factor = 1.0 + uBrightness / 100.0; gl_FragColor = vec4(color.rgb * factor, color.a); }` ); } get brightness(): number { return this.uniforms.uBrightness; } set brightness(value: number) { this.uniforms.uBrightness = value; } }

这个自定义 Filter 使用线性公式color.rgb * (1 + value/100)，完全规避了Math.pow的精度问题。实测 100 次往返拖动后，图像亮度误差小于 0.001%，人眼不可辨。

5.4 Svelte 组件中的“状态幽灵”：为什么图层删除后画布没更新？

现象：用户点击图层面板的“删除”按钮，editorStore.update()正确移除了图层数组中的元素，但画布上该图层依然显示。

根因：Svelte 的$:响应式在处理数组时，只监听数组引用的变化，不监听数组内部元素的增删。`editorStore.update(state => ({ ...state, layers: state