箭头函数不直接优化内存，但配合享元模式可简化无副作用逻辑，减少对象创建；享元通过共享不可变内在状态（如字体、滤镜、画笔配置）并复用实例实现内存精简，辅以弱引用缓存与管线协同。
箭头函数本身不直接参与内存优化，但它能配合享元模式写出更简洁、无副作用的客户端逻辑，从而减少意外对象创建和状态污染——真正起内存精简作用的是享元模式的状态分离与对象复用机制。
明确享元核心：只共享不可变的内在状态
在亿级像素编辑器中，大量图层、滤镜参数、画笔样式、字体配置等存在高度重复性。例如，10万次“高斯模糊半径=2”的操作，不应创建10万个相同配置对象。需提取出不可变部分作为内在状态：
- 字体样式（font family、size、weight、color）→ 封装为 CharacterStyle 享元类，构造后禁止 setter
- 滤镜参数（如 brightness=1.2, contrast=1.1）→ 定义为 FilterConfig 不可变类，用 final 字段或 record（Java 14+）保证不可变
- 画笔属性（strokeWidth=3, cap=ROUND, join=MITER）→ 统一由 BrushProfile 享元管理
这些对象一旦创建，就放入享元工厂缓存池，后续请求相同配置时直接返回已有实例，避免重复分配堆内存。
用箭头函数简化客户端调用，规避闭包内存泄漏
传统回调写法易因 this 绑定或变量捕获导致意外引用，延长对象生命周期。箭头函数天然绑定外层词法作用域，且无自身 this/arguments，适合用于传递外部状态：
- 渲染每块图像区域时，传入坐标、缩放比等 外部状态，用箭头函数封装操作逻辑：
region.render((x, y, scale) => painter.draw(layer, x, y, scale, style)) - 事件处理器中避免捕获大对象：
✅ 好：canvas.addEventListener('click', () => editor.applyFilter(activeFilterKey))
❌ 差：canvas.addEventListener('click', function() { this.editor.applyFilter(this.activeFilter) })（this 可能持有多余引用） - 享元操作方法接收外部状态，箭头函数确保不引入额外闭包变量：
const renderOp = (pos, zoom) => flyweight.render(pos, zoom, currentCanvasContext)
工厂 + 缓存 + 弱引用：防止享元池无限膨胀
亿级场景下，仅靠 HashMap 缓存可能积累冷门配置（如用户临时尝试的极端滤镜组合）。需主动治理：
- 享元工厂使用 WeakHashMap 或 ConcurrentHashMap + LRU 驱逐策略，对极少复用的配置自动清理
- 键设计采用不可变、可哈希的组合对象（如
FilterKey.of("blur", 2.0, "px")），而非字符串拼接，避免哈希冲突与冗余对象 - 对像素级操作（如蒙版、选区）不强行享元化——它们本质是外部状态密集型，应交由 WebAssembly 模块原地处理，避免 Java/JS 层对象化
与高像素图片处理链路深度协同
享元模式必须嵌入整个图像处理管线，而非孤立使用：
- 降采样阶段：不同缩略图尺寸共用同一组 ResampleStrategy 享元（如 Lanczos3、Bilinear）
- 区域解码：每个可视区域请求携带 RegionRequest 外部状态，享元解码器复用纹理加载器、色彩空间转换器等内在组件
- 上传前压缩：将压缩质量、格式（WebP/AVIF）、渐进模式打包为 ExportProfile 享元，百万张图仅需几十个实例
此时，箭头函数常用于快速组装 pipeline 步骤：pipeline.then(data => decode(data, region)).then(img => applyFilter(img, filterFlyweight)).then(...)
