享元模式在Go中通过结构体封装内在状态、函数参数传递外在状态，并用sync.Pool或map实现复用；避免接口抽象和指针接收者，强调值语义与状态划分。
Go 没有传统面向对象语言里的“抽象享元类”或“工厂管理实例池”的强制范式，它的享元本质是：**用结构体封装可共享的内在状态（intrinsic state），通过函数参数传入不可共享的外在状态（extrinsic state），再配合 sync.Pool 或 map 实现对象复用**。强行套用 Java/C# 的类继承结构反而会增加 GC 压力和接口抽象成本。
400-7654-355 sync.Pool 复用轻量结构体实例sync.Pool 是 Go 标准库中为享元场景设计的最直接工具，适合生命周期短、创建开销明显、且状态可重置的结构体。注意它不保证对象一定被复用，也不自动清理，必须手动重置字段。
Pool.Get() 取出的对象，其字段值是未定义的，必须显式初始化或清空Pool，否则可能引发内存泄漏或数据污染Pool.New 函数只在首次 Get 且池为空时调用，不能依赖它做 per-Get 初始化type CharFont struct {
Name string
Size int
Bold bool
}
var fontPool = sync.Pool{
New: func() interface{} {
return &CharFont{}
},
}
func GetFont(name string, size int, bold bool) CharFont {
f := fontPool.Get().(CharFont)
f.Name = name
f.Size = size
f.Bold = bold
return f
}
func PutFont(f *CharFont) {
// 清空字段，避免下次误用残留值
f.Name = ""
f.Size = 0
f.Bold = false
fontPool.Put(f)
}
map[string]*T 管理带键的享元对象当享元需按唯一键长期存在（比如字体名+字号组合）、且数量可控时，用 map 更合适。它能精确控制生命周期，支持并发安全（需加锁），也便于调试和统计。
struct{ Name string; Size int; Bold bool } 而非拼接字符串，避免哈希冲突与解析开销sync.RWMutex 提升并发读性能type FontKey struct {
Name 
string
Size int
Bold bool
}
var fontCache = struct {
sync.RWMutex
m map[FontKey]CharFont
}{
m: make(map[FontKey]CharFont),
}
func GetCachedFont(name string, size int, bold bool) *CharFont {
key := FontKey{Name: name, Size: size, Bold: bold}
fontCache.RLock()
if f, ok := fontCache.m[key]; ok {
fontCache.RUnlock()
return f
}
fontCache.RUnlock()
fontCache.Lock()
defer fontCache.Unlock()
if f, ok := fontCache.m[key]; ok {
return f
}
f := &CharFont{Name: name, Size: size, Bold: bold}
fontCache.m[key] = f
return f}
为什么不该用指针接收者实现 Flyweight 接口
Go 社区有时会尝试定义 type Flyweight interface { Render(extrinsic string) } 并让结构体实现它，但这违背享元本意——享元不是为了多态，而是为了减少重复对象。接口值本身就有 16 字节开销，且接口变量会阻止编译器内联，还可能意外逃逸到堆上。
func renderText(font *CharFont, content string)，调用方直接传共享结构体指针真正难的不是写对代码，而是判断哪些状态该进享元、哪些该作为参数传入——比如颜色通常属于外在状态，而字体度量信息（ascent/descent）才是典型的内在状态。这个划分一旦出错，共享就变成竞态。
