享元模式的核心是对象池加键值分离，需用WeakValueDictionary缓存不可变内在状态，剥离可变外部状态，避免内存泄漏与无效复用。
享元模式的核心不是“写个类”，而是对象池+键值分离
Python里实现享元，关键不是照搬GoF的UML图，而是用 dict 或 weakref.WeakValueDictionary 做对象缓存，并把“可变状态”（extrinsic state）从享元对象本身剥离出去。否则你写了个 Flyweight 类，但每次还新建实例，等于没做。
典型错误是把所有字段都塞进享元类里，结果对象无法复用——比如把用户ID、时间戳这些随上下文变化的属性也放进享元，那就违背了“共享不可变内部状态”的前提。
- 享元类只保留
font_name、font_size、color这类可跨多个文本块复用的属性 - 坐标、内容、所属文档ID 这些必须由调用方传入，不保存在享元实例中
- 用
__key = (font_name, font_size, color)作为缓存键，推荐用typing.NamedTuple或dataclasses.frozen=True保证可哈希
用 WeakValueDictionary 防止内存泄漏
如果直接用普通 dict 缓存享元，又没手动清理，对象会一直驻留内存，尤其在长生命周期应用（如GUI、Web服务）里容易OOM。Python的 weakref.WeakValueDictionary 是更安全的选择——当外部不再持有引用时，对应享元自动被回收。
注意：它只对“值”做弱引用，所以键仍需是不可变且可哈希的；同时，不能用它存带 __del__ 的对象，否则行为未定义。
立即学习“Python免费学习笔记（深入）”；
- 初始化缓存：
self._pool = weakref.WeakValueDictionary() - 获取享元时先查缓存：
obj = self._pool.get(key)，没有再创建并存入 - 不要在享元类里定义
__del__，避免干扰弱引用回收
字符串 intern 和享元不是一回事
有人看到“对象复用”就想到 sys.intern()，但它只对字符串生效，且仅保证相同字面量指向同一对象，不适用于自定义类或结构化数据。享元是主动设计的对象复用策略，控制粒度更细、适用范围更广。
比如渲染10万行日志，每行用不同颜色但只有5种字体组合，用享元能把字体对象从10万个减到5个；而 sys.intern() 对 Font('Consolas', 12, 'red') 这种构造式调用完全无效。
-
sys.intern()适合短生命周期字符串去重（如解析CSV列名） - 享元适合有明确“内在状态”分类边界的对象（如字符样式、图形笔刷、数据库连接配置）
- 二者不互斥，但目标不同：一个是解释器级优化，一个是架构层设计
别在小规模场景强行套享元
如果总共只创建几十个对象，或者对象本身极轻量（比如只有1–2个int字段），加享元反而增加哈希计算、字典查找、弱引用管理的开销，性能可能更差。Python的内存分配本身已很高效，过早优化容易引入复杂度。
真正值得上享元的信号是：对象创建耗时明显（如含I/O或复杂计算）、内存占用高（如带大数组或嵌套结构）、且存在大量重复状态组合。
- 用
memory_profiler或tracemalloc实测对象数量和内存占比 - 确认重复状态比例 > 30% 再引入享元逻辑
- 优先考虑用
@lru_cache替代手写缓存，尤其当构造函数参数少且确定
享元最难的部分从来不是代码怎么写，而是准确识别哪些状态真的“可共享”、哪些只是你以为能共享。多一次状态分析，比多写十行缓存逻辑更有价值。
