享元模式通过轻量接口（如itextureflyweight）定义渲染契约，将千万级纹理的只读元数据按格式、尺寸等特征聚类为唯一键归一化管理，gpu资源与元数据分离实现热替换，运行时参数通过方法注入避免拷贝。
直接用接口配合享元模式统一复用千万级异构纹理元数据，核心不是“堆接口”，而是把纹理中真正可共享的部分抽出来、管住、按需注入外部变化。关键在于接口只定义行为契约，不承载状态；真正做减法的是享元工厂对元数据的归一化管理。
接口只暴露渲染契约，不封装纹理数据
定义轻量接口（如 ITextureFlyweight），仅声明 bind(int slot)、updateUVOffset(Vector2 offset) 这类与渲染管线交互的方法。接口里不存宽高、格式、mipmap层级等元数据——这些全交给具体享元内部持有，且必须是只读的、构造时确定的。
这样做的好处：不同来源的纹理（DDS、ASTC、RuntimeGenerated）只要实现同一接口，就能被同一套绘制逻辑调用；而元数据差异被隔离在具体类内部，不影响上层调度。
按元数据特征聚类，而非按文件名或路径
千万级纹理看似各异，实际元数据维度有限：格式（RGBA8/BC3/etc）、尺寸（常为2的幂次）、mipmap开关、sRGB标记、采样方式（clamp/wrap）。把这些字段组合成唯一键（如 "BC3_1024x1024_true_false"），作为享元工厂的缓存键。
示例操作：
- 加载一张ASTC 512×512带mipmap的sRGB纹理 → 提取元数据生成键 → 工厂返回已存在的对应享元实例
- 另一张PNG 512×512无mipmap非sRGB → 键不同 → 新建享元，但复用相同的GPU资源绑定逻辑和Shader参数布局
元数据与GPU资源分离，支持热替换与版本管理
具体享元类（如 CompressedTextureFlyweight）内部只持有一个 ResourceHandle（指向GPU内存地址或句柄索引），不直接持有像素数据。元数据（格式、尺寸等）用于校验、预分配、着色器宏选择；真实GPU资源由资源系统统一生命周期管理。
这样当某类纹理需要更新（比如压缩算法升级），只需刷新对应键的GPU资源，所有引用该键的享元自动生效，无需重建对象、不触发GC、不打断渲染帧。
外部状态精准注入，避免运行时拷贝
位置、UV偏移、混合系数等每帧变动的参数，绝不能塞进享元对象。客户端（如渲染器模块）在绘制前，通过接口方法传入这些值，由享元内部调用底层API（如 glUniform 或 Vulkan descriptor update）直接写入命令缓冲区。
例如：flyweight.bindAndApply(0, new TextureParams().setUvOffset(uv).setBlendMode(ADD)) —— 这个调用不改变享元自身，只组织一次高效的状态提交。
