Go中享元模式靠值复用、sync.Pool或map缓存+不可变数据实现，强调struct不可变、避免指针暴露、慎用sync.Pool及可比较key，核心是合理分离内外状态。
Go 语言本身没有类和继承，也不鼓励用“模式”硬套设计，享元模式在 Go 里不是靠抽象结构实现的，而是靠值复用、sync.Pool 或 map 缓存 + 不可变数据来达成内存节省目的。直接照搬 Java 那套 FlyweightFactory + Flyweight 接口，在 Go 里反而容易写出过度设计、GC 压力大或并发不安全的代码。
享元对象必须是不可变的（immutable）
享元的核心前提是：多个地方共享同一个实例，那它就不能被任意修改。Go 中最自然的不可变载体是 struct（字段全为导出/非指针基础类型或只读 slice），配合构造函数约束初始化路径。
- 避免暴露可变字段，比如
type Icon struct { Data []byte }→ 改成type Icon struct { data []byte }（小写字段）+ 提供只读方法Data() []byte返回拷贝 - 如果内部含指针或 map/slice，务必在构造时 deep copy 或冻结（如用
sync.Map替代原生map仅作查找，不暴露写入口） - 常见错误：把
*Icon当享元返回，结果调用方一改就污染所有使用者
用 sync.Pool 替代手动 FlyweightFactory
Go 标准库的 sync.Pool 就是为“多协程复用临时对象”而生的，比手写 map + mutex 更轻量、更符合 Go 的内存管理习惯，且自动适配 GC 周期。
- 不要自己实现带锁的全局 map 缓存，尤其在高并发下易成瓶颈；
sync.Pool的本地池机制能显著减少锁竞争 -
sync.Pool的New函数应返回**已初始化好、可直接用**的对象，比如预分配好固定大小的 buffer - 注意：Pool 中的对象可能被 GC 回收，不能依赖其长期存在；适合生命周期短、创建开销大的对象（如 JSON 解析器、临时 buffer、图标解码中间结构）
- 示例：
var iconPool = &sync.Pool{ New: func() interface{} { return &Icon{data: make([]byte, 0, 1024)} }, }
按 key 缓存享元时，key 必须可比较且稳定
当需要根据参数（如文件名、尺寸、主题）生成唯一享元时，用 map[key]Flyweight 是常见做法，但 key 类型选错会导致 panic 或缓存失效。
立即学习“go语言免费学习笔记（深入）”；
- 禁止用 slice、map、func 作为 map key —— Go 编译时报错：
invalid map key type []byte - 推荐组合方式：
struct{ Name string; Size int; Theme string }（所有字段可比较），或用fmt.Sprintf("%s-%d-%s", name, size, theme)转字符串（简单场景够用） - 如果 key 含不定长数据（如原始图片 bytes），先算
sha256.Sum256再转为 [32]byte —— 可比较、定长、冲突率低 - 并发读写该 map 时，必须加
sync.RWMutex，且读多写少场景优先用RLock()
真正难的不是怎么写一个 FlyweightFactory，而是判断哪些状态该放进享元、哪些必须由外部传入（即“外部状态”）。比如图标渲染，颜色可能是外部状态（每次调用传入），而图元拓扑结构才是享元本体。这个边界一旦划错，缓存就失去意义，甚至引发竞态。
