go中flyweight模式应基于结构体字段复用与指针共享，用sync.pool或惰性初始化map管理不可变享元，避免interface{}、反射及错误池化。
Go 语言没有传统面向对象的继承体系，也不支持抽象类或接口的多重实现约束，但 Flyweight 模式依然可落地——关键不在“如何模仿 Java 写法”，而在“如何用 Go 的值语义、sync.Pool 和不可变数据结构规避重复分配”。
为什么 Go 中的 Flyweight 不该依赖 interface{} 或反射
常见误区是定义一个 Flyweight 接口，再让各种“享元”去实现。这会导致：类型擦除、逃逸分析失败、GC 压力上升。Go 的高效享元应基于「结构体字段复用 + 指针共享」而非运行时多态。
- 内部状态（intrinsic state）必须是不可变的，通常用
struct字面量或只读字段封装 - 外部状态（extrinsic state）绝不存于享元实例中，而由调用方传入函数参数
- 避免把
map[string]*Flyweight当作享元工厂——它会持续增长且无法 GC；改用sync.Map或预建固定池
用 sync.Pool 实现轻量级享元池（适用于短生命周期对象）
当享元对象创建开销大、但使用后很快丢弃（如解析器 token、网络包头缓存），sync.Pool 比手动管理 map 更安全、更省内存。
var headerPool = sync.Pool{
New: func() interface{} {
return &PacketHeader{Version: 1, Flags: 0}
},
}
func GetHeader() *PacketHeader {
return headerPool.Get().(*PacketHeader)
}
func PutHeader(h *PacketHeader) {
h.Flags = 0 // 重置可变字段
headerPool.Put(h)
}
注意：sync.Pool 不保证对象复用率，且 GC 会清空其内容；不能用于需长期持有或跨 goroutine 共享的享元。
立即学习“go语言免费学习笔记（深入）”；
用 map + sync.Once 实现全局唯一享元（适用于静态配置类对象）
若享元代表协议常量、字符编码表、HTTP 方法枚举等只读数据，适合用惰性初始化的全局 map：
type Charset struct {
Name string
ID uint8
}
var (
charsetMu sync.RWMutex
charsetMap = make(map[string]*Charset)
)
func GetCharset(name string) *Charset {
charsetMu.RLock()
if c, ok := charsetMap[name]; ok {
charsetMu.RUnlock()
return c
}
charsetMu.RUnlock()
charsetMu.Lock()
defer charsetMu.Unlock()
if c, ok := charsetMap[name]; ok { // double-check
return c
}
c := &Charset{Name: name, ID: uint8(len(charsetMap))}
charsetMap[name] = c
return c
}
- 所有
Charset实例字段必须不可变（不提供 setter，不暴露指针给外部修改） - 避免用
unsafe.Pointer或reflect绕过字段只读性，否则破坏享元语义 - 若 key 空间可控（如 HTTP method 只有几十种），可直接用
[256]*Charset替代 map，零锁加速
别把字符串拼接、time.Time 当享元来池化
Go 中 string 本身已是不可变引用类型，底层指向只读字节数组；time.Time 是值类型，拷贝成本极低。强行池化这类对象不仅没收益，反而因 sync.Pool.Put 引入额外同步开销。
真正值得享元化的，是含大量字段、频繁 new 出又立即丢弃的结构体（比如 AST 节点、正则匹配上下文、加密上下文句柄）。判断标准只有一个：pprof 显示该类型在堆上高频分配且存活时间短。
