享元模式在Go中通过结构体封装内在状态、函数参数传递外在状态，并用sync.Pool或map实现复用；避免接口抽象和指针接收者，强调值语义与状态划分。
享元模式在 Go 中的核心实现思路
Go 没有传统面向对象语言里的“抽象享元类”或“工厂管理实例池”的强制范式，它的享元本质是：**用结构体封装可共享的内在状态（intrinsic state），通过函数参数传入不可共享的外在状态（extrinsic state），再配合 sync.Pool 或 map 实现对象复用**。强行套用 Java/C# 的类继承结构反而会增加 GC 压力和接口抽象成本。
用 sync.Pool 复用轻量结构体实例
sync.Pool 是 Go 标准库中为享元场景设计的最直接工具，适合生命周期短、创建开销明显、且状态可重置的结构体。注意它不保证对象一定被复用，也不自动清理，必须手动重置字段。
- 每次从
Pool.Get()取出的对象，其字段值是未定义的，必须显式初始化或清空 - 不要把含指针字段（尤其是指向大对象或闭包）的结构体放进
Pool，否则可能引发内存泄漏或数据污染 -
Pool.New函数只在首次 Get 且池为空时调用，不能依赖它做 per-Get 初始化
type CharFont struct {
Name string
Size int
Bold bool
}
<p>var fontPool = sync.Pool{
New: func() interface{} {
return &CharFont{}
},
}</p><p>func GetFont(name string, size int, bold bool) <em>CharFont {
f := fontPool.Get().(</em>CharFont)
f.Name = name
f.Size = size
f.Bold = bold
return f
}</p><p>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提升并发读性能 - 不要在 map 中存含 mutex 或 channel 的结构体，会导致 panic
type FontKey struct {
Name string
Size int
Bold bool
}
<p>var fontCache = struct {
sync.RWMutex
m map[FontKey]<em>CharFont
}{
m: make(map[FontKey]</em>CharFont),
}</p><p>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()</p><pre class='brush:php;toolbar:false;'>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}
立即学习“go语言免费学习笔记（深入）”；
为什么不该用指针接收者实现 Flyweight 接口
Go 社区有时会尝试定义 type Flyweight interface { Render(extrinsic string) } 并让结构体实现它，但这违背享元本意——享元不是为了多态，而是为了减少重复对象。接口值本身就有 16 字节开销，且接口变量会阻止编译器内联，还可能意外逃逸到堆上。
- 优先用函数代替接口：如
func renderText(font *CharFont, content string)，调用方直接传共享结构体指针 - 如果必须抽象行为（比如不同渲染后端），应把差异点抽成函数类型字段，而非整个接口
- 所有享元相关操作尽量保持值语义清晰：谁负责传参、谁负责复用、谁负责清理，边界要明确
真正难的不是写对代码，而是判断哪些状态该进享元、哪些该作为参数传入——比如颜色通常属于外在状态，而字体度量信息（ascent/descent）才是典型的内在状态。这个划分一旦出错，共享就变成竞态。
