享元模式在Go中通过分离内在状态（不可变、共享）与外在状态（上下文相关、调用时传入）实现内存优化；使用只读结构体封装内在状态，sync.Map工厂管理线程安全复用，sync.Pool辅助短期对象回收。
享元模式的核心是将对象中可共享的、不变的部分（内在状态）提取出来，由多个对象共用，从而减少内存占用和对象创建开销。在 Go 中，由于没有类继承体系，我们通过结构体、接口和对象池等机制来实现——关键在于分离内在状态与外在状态，并确保共享部分是线程安全且不可变的。
用结构体封装内在状态，避免重复分配
内在状态是享元对象共用的数据，必须不可变（如字体名、颜色值、图标路径）。Go 中推荐用只读字段或不导出字段 + 构造函数控制初始化：
- 定义一个轻量结构体，仅包含不可变字段（如 string、int、bool 等值类型，或指向不可变数据的指针）
- 禁止外部直接修改；若需复杂数据（如 map/slice），应深拷贝或使用 sync.Map 封装只读视图
- 例如：type FontStyle struct { Name string; Size int; Bold bool } —— 所有字段均为值类型，天然不可变
用工厂管理享元实例，按需复用
享元工厂负责缓存和返回已存在的内在状态对象。Go 中常用 sync.Map 或带锁的 map 实现线程安全的单例查找：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 键通常是内在状态的组合哈希（如 fmt.Sprintf("%s-%d-%t", name, size, bold)）
- 首次请求时新建并缓存；后续请求直接返回已有指针
- 避免用 map + sync.RWMutex 在高并发下频繁读锁，sync.Map 更适合读多写少场景
外在状态由调用方传入，不保存在享元内
位置、透明度、用户ID 等随上下文变化的数据，绝不能放进享元结构体。应在使用时作为参数传入方法：
立即学习“go语言免费学习笔记（深入）”；
- 享元接口方法签名形如：func (f *FontStyle) Render(text string, x, y int, alpha float32)
- 这样同一个 FontStyle 实例可被成千上万个文本元素复用，仅消耗一份内存
- 若误把 x/y 存进结构体，就失去了享元意义，变成普通对象
配合 sync.Pool 进一步降低临时对象压力
对于需频繁创建/销毁但又非全局共享的“半享元”对象（如渲染上下文、临时缓冲区），可用 sync.Pool 回收复用：
- 享元本身是长期存活的（如字体样式），而 sync.Pool 适合短期对象（如每次绘制生成的 GlyphBatch）
- 注意：Pool 中对象无生命周期保证，不能存放含闭包、未释放资源或依赖外部状态的对象
- 典型组合：享元提供样式，Pool 提供绘制容器，两者协作减少 GC 压力
