17370845950

享元模式核心是“共享+不可变+外部化”，即提取不变的内在状态复用，将变化的外在状态由调用方传入；Go中通过不可变结构体、sync.Pool管理与参数注入实现。

享元模式的核心思想

享元模式（Flyweight Pattern）本质是“共享+不可变+外部化”。它把对象中可共享的、不变的状态（内在状态）提取出来复用，而将依赖上下文的、变化的部分（外在状态）由调用方传入。在 Go 中，这通常体现为：一个轻量结构体（享元） + 一个对象池（sync.Pool 或自定义缓存） + 外部传参处理差异化逻辑。

Go 中实现享元对象池的三步关键操作

不需要复杂框架，用原生特性就能高效落地：

• 定义不可变享元类型：字段全为基本类型或只读指针（如 string、int、*sync.RWMutex 不推荐，但 *config 可接受），不保存任何请求相关数据；方法只读，不修改自身
• 用 sync.Pool 管理实例：New 字段返回新享元指针，Pool 自动复用；注意 Pool 中对象可能被 GC 清理，适合高频短生命周期场景（如 HTTP 请求处理）
• 外在状态通过函数参数注入：比如享元负责渲染模板，但具体用户 ID、时间戳等由调用方传入；享元内部不存这些值，也不设 setter

一个真实可用的文本格式化享元示例

假设多个服务需频繁格式化日志消息，共用相同的格式规则（前缀、分隔符、时区），但每条日志内容不同：

type LogFormatter struct {
    prefix    string
    separator string
    loc       *time.Location // 内在状态：固定不变
}

func (f *LogFormatter) Format(msg string, ts time.Time) string {
    return fmt.Sprintf("%s%s[%s]%s%s", 
        f.prefix, f.separator, 
        ts.In(f.loc).Format("15:04:05"), 
        f.separator, msg)
}

var formatterPool = sync.Pool{
    New: func() interface{} {
        return &LogFormatter{
            prefix:    "[APP]",
            separator: " | ",
            loc:       time.UTC,
        }
    },
}

// 使用时：
f := formatterPool.Get().(*LogFormatter)
output := f.Format("user login", time.Now())
formatterPool.Put(f) // 归还，供下次复用

注意：Put 前确保享元未被并发修改，否则会破坏不可变性；若需并发安全，享元本身应完全无状态，或用只读字段 + 参数驱动。

什么时候该用，什么时候别硬套？

享元在 Go 中不是银弹。适用场景很明确：

• 对象创建开销大（如含正则编译、连接初始化），且存在大量重复配置
• 内存敏感，对象数量达万级甚至更多，且多数字段雷同
• 你能清晰区分哪些是内在状态（可共享）、哪些必须每次传入（外在状态）

不适用的情况包括：对象天然唯一（如代表某次请求的 RequestCtx）、状态频繁变更、或复用收益远小于代码复杂度增加——这时 plain struct + sync.Pool 就够了，不必强行套享元术语。

基本上就这些。享元不是语法糖，而是对“复用边界”的一次主动设计。写清楚内在/外在，管住 mutability，池子自然就稳了。