享元对象必须不可变以保证线程安全；go 中应将变化数据外提，用 sync.pool 管理享元池，键优先用字符串字面量或 iota，避免与单例混淆。
享元对象必须是不可变的，否则线程不安全
Go 语言没有内置的享元模式支持，但它的并发模型和结构体语义天然适合实现享元——前提是 Flyweight 类型本身不可变。一旦在 struct 中暴露可修改字段（比如指针、切片、map），多个 goroutine 共享该实例时就会引发数据竞争。
常见错误是把配置参数塞进享元实例里，例如：
type Icon struct {
Name string
Size int // ❌ 可变字段，不同调用方可能改它
}
正确做法是把变化的部分外提，只让享元承载「共享状态」：
- 享元结构体所有字段都应为值类型或只读引用（如
*sync.Map仅用于内部缓存，不对外暴露写接口） - 运行时差异数据（如位置、颜色、ID）必须由调用方传入，不保存在享元中
- 用
go vet -race检查数据竞争，尤其注意初始化后是否被意外修改
用 sync.Pool 替代手动管理享元池更轻量
很多人用 map[string]*Flyweight + sync.RWMutex 实现享元工厂，但这在高频创建/销毁场景下会成为瓶颈。Go 标准库的 sync.Pool 更适合作为享元缓存容器，它按 P（processor）分片，无锁访问，且自动 GC 友好。
立即学习“go语言免费学习笔记（深入）”；
关键点：
-
sync.Pool的New字段必须返回新分配的享元实例，不能返回已有对象的指针（否则破坏享元“共享”语义） - 不要在
Get()后直接复用对象而不重置——sync.Pool不保证返回的是干净实例，需手动清空非共享字段 - 适用于生命周期短、构造开销大的对象，比如 JSON 解析器、正则
*regexp.Regexp缓存、小尺寸图像像素数据结构
示例：
var iconPool = sync.Pool{
New: func() interface{} {
return &Icon{Type: "default", Data: make([]byte, 0, 64)}
},
}
func GetIcon(iconType string) *Icon {
icon := iconPool.Get().(*Icon)
icon.Type = iconType // 重置共享字段以外的状态
return icon
}
func PutIcon(icon *Icon) {
icon.Type = "" // 清理业务字段，保留缓冲区
iconPool.Put(icon)
}
字符串字面量和 iota 常量天然适合做享元键
享元工厂需要快速查找已存在实例，而 Go 中最高效、零分配的 key 类型就是字符串字面量和 iota 枚举值。避免用 fmt.Sprintf 或 strconv.Itoa 动态拼接 key，这会触发堆分配并降低缓存命中率。
典型误用：
key := fmt.Sprintf("%s-%d", name, size) // ❌ 每次都 new string
推荐方式：
- 预定义常量：
const IconHome = "home"，然后直接用IconHome当 key - 用
iota定义图标类型枚举，再用int作 map key（比 string 查找快 2–3 倍） - 若必须动态生成，先查
map[string]struct{}判断是否存在，再决定是否新建，而不是每次都map[key] = new(...)
嵌入 sync.Once 的享元初始化容易掩盖竞态
有些实现用 sync.Once 控制享元单例初始化，比如：
var once sync.Once
var instance *HeavyResource
func GetResource() *HeavyResource {
once.Do(func() {
instance = newHeavyResource() // 耗时操作
})
return instance
}
问题在于：如果 newHeavyResource() 返回的是可变对象（如含未同步的 map 或 slice），后续所有使用者都在操作同一份底层数据。这不是享元模式的问题，而是误把「单例」当「享元」。
真正享元的关键是「状态分离」：
- 共享部分（如纹理数据、字体度量）可以单例初始化
- 非共享部分（如渲染坐标、用户 ID）绝不能混入该实例
- 若初始化逻辑复杂，优先用
sync.Pool+ 预热（warm-up）而非sync.Once
最容易被忽略的是：享元不是为了“少 new”，而是为了“少拷贝共享数据”。如果共享内容本身很小（比如几个 int），用享元反而增加间接寻址开销。
