先说几个核心判断：享元模式在C#中并非"必须用"，而是当你发现内存里堆着大量重复、细粒度对象（比如上万个小图标、字符样式、棋子实例），且它们的状态可拆分为「内在状态」和「外在状态」时，才值得引入——否则就是过度设计。如果对象需要Dispose、含事件订阅或依赖this引用，那基本可以放弃享元化的念头。
什么时候该用 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）作为内在状态的一部分
真正难的不是写对工厂和接口，而是判断哪些状态属于"内在"、哪些必须剥离出去——这需要你画出对象图，标出哪些字段在所有实例中完全一致，哪些随上下文跳变。画不出来，就先别上享元。毕竟，设计模式是来解决问题的，不是为了制造问题。
