享元模式适用于大量重复细粒度对象且状态可分内在/外在时，如字体、字符实例；若对象需Dispose、含事件订阅或依赖this则不适用。
享元模式在 C# 中不是“必须用”，而是当你发现内存里堆着大量重复、细粒度对象（比如上万个小图标、字符样式、棋子实例），且它们的状态可拆分为「内在状态」和「外在状态」时，才值得引入——否则就是过度设计。
什么时候该用 IFlyweight 而不是直接 new 对象
典型信号是：你正在循环创建大量相似对象，每个只差一两个字段（如坐标、颜色、ID），而这些差异能被外部传入；同时对象本身不保存上下文，也不持有引用其他业务实体。
- 常见场景：
System.Drawing.Font复用（字体名+大小+样式固定，但绘制位置每次不同）、文本编辑器中成千上万个Character实例（字符本身不变，位置/高亮状态由行渲染器控制） - 反模式信号：对象有生命周期管理（如需 Dispose）、内部含事件订阅、依赖
this引用调用其他服务——这类不适合享元化 - 性能影响：享元工厂首次访问有哈希查找开销，但后续复用省下 GC 压力；若对象总数
FlyweightFactory.GetFlyweight(string key) 的 key 设计要点
key 不是随便拼的字符串，它必须唯一、稳定、无歧义地标识一组内在状态。别用 ToString() 或 JSON 序列化结果作 key——太重且易出错。
- 推荐方式：用
ValueTuple（C# 7.0+）或自定义struct作为 key，例如(string fontName, float size, FontStyle style) - 避免方式：用
new { Name = "Arial", Size = 12 }—— 匿名类型每次 new 都是新类型，Dictionary查不到 - 注意线程安全：如果工厂被多线程调用，
ConcurrentDictionary比手动加锁更稳妥
外在状态怎么传给 IFlyweight.Operation(externalState)
享元接口的 Operation 方法必须接收所有变化的数据，不能靠闭包捕获、也不能存字段——那是破坏享元本质。
- 正确做法：把坐标、渲染上下文、用户 ID 等每次不同的数据，作为参数传入，例如
flyweight.Render(graphics, x, y, isHighlighted) - 错误做法：在享元类里设
public int X { get; set; }，然后外部反复赋值——这会让对象失去共享安全性 - 边界提醒：如果参数超过 4–5 个，说明外在状态可能没合理分层，考虑封装成
RenderContext类，但别让它带业务逻辑
为什么 ConcreteFlyweight 必须是不可变的
因为多个地方共用同一个实例，一旦某个调用方改了它的字段，其他调用方立刻看到脏数据——这不是 bug，是设计失效。
- 强制手段：所有字段声明为
readonly，构造函数一次性注入内在状态，不提供 public setter - 例外情况：极少数场景需延迟初始化（如图片资源首次访问才加载），可用
Lazy，但初始化逻辑仍要线程安全 - 调试提示：若发现享元行为异常，优先检查是否无意中修改了字段，或用了可变集合（如
List）作为内在状态的一部分
真正难的不是写对工厂和接口，而是判断哪些状态属于“内在”、哪些必须剥离出去——这需要你画出对象图，标出哪些字段在所有实例中完全一致，哪些随上下文跳变。画不出来，就先别上享元。
