享元模式是通过共享内部状态、分离外部状态来减少对象数量的设计模式。内部状态不变且可共享，如颜色、型号；外部状态动态且由客户端传入，如坐标、价格；需用工厂管理实例池，避免重复创建，并注意适用边界。

享元模式不是“多建几个对象”，而是“该共享的绝不重复建”。它专治那种成千上万对象中，只有几组属性反复出现的场景——比如 100 万个商品规格里，其实就 23 种颜色、15 种尺寸、8 种材质；又比如游戏里 5000 只飞龙，模型、技能、贴图完全一样，只差坐标和血量。

明确区分内部状态与外部状态

这是享元模式落地的第一道门槛，也是最容易出错的地方：

• 内部状态：不变、可共享、属于“模板”级数据。例如商品的 color="红色"、字体的 fontFamily="微软雅黑"、飞龙的 modelId="dragon_v2"。这些值在创建后不随上下文变化，可安全复用。
• 外部状态：动态、不可共享、由调用方传入。例如商品的 id、price、stock；字符的 positionX、lineNumber；飞龙的 x、y、hp。它们必须从享元对象中剥离，由客户端持有并按需传入方法。

混淆二者会导致数据污染——比如把价格塞进享元对象，所有共享该对象的商品就显示同一价格了。

用工厂类统一管理享元实例池

享元不能靠 new 随意创建，必须经由工厂管控。工厂本质是一个带缓存的映射表：

• 以内部状态组合为 key（如 "红色-M-L-棉" 或 "A-14-bold"），查表返回已有实例；
• 首次请求时才新建，并存入 map；
• 推荐使用 ConcurrentHashMap（Java）或线程安全容器，避免多线程下重复初始化。

工厂不负责外部状态，也不保存任何运行时上下文——它只管“谁长得一样，就发同一个身份证”。

客户端调用要主动传递外部状态

享元对象的方法签名通常显式接收外部参数：

• 错误写法：spec.display()（试图在内部读取 price/stock，但这些不在 spec 里）；
• 正确写法：spec.display(productId, price, stock) 或 spec.render(x, y, rotation)；
• 关键点：display/render 等行为逻辑仍由享元执行，但所需变量由外部提供，实现“逻辑复用 + 数据隔离”。

注意边界与取舍

享元模式不是银弹，用错反而增加复杂度：

• 对象数量少于几百个时，优化收益微乎其微，还白添一层抽象；
• 内部状态组合爆炸（如 100 种颜色 × 100 种尺寸 × 100 种材质 = 100 万种 key），缓存本身会吃内存，此时应考虑分层缓存或降维（比如只共享材质+尺寸，颜色走外部）；
• 若内部状态频繁变更（如“库存数”被误当内部状态），共享将失效甚至引发并发问题——这类数据必须划归外部。