Go中备忘录模式的核心难点是确保仅Originator可读写Memento而Caretaker只能持有：需用全导出字段的不可变结构体，深拷贝复杂状态，限制历史快照数量防内存泄漏，并避免存储临时资源句柄。
备忘录模式在 Go 中的核心实现难点
Go 没有内置的类、继承或访问控制（如 private），所以无法像 Java/C# 那样靠封装强制隔离备忘录内部状态。真正的难点不是“怎么存”，而是“怎么确保只有原发起者（Originator）能读写备忘录内容，而管理者（Caretaker）只能持有、不能篡改”。否则回滚就失去意义。
Memento 必须是不可变结构体 + 原始字段暴露
常见错误是把 Memento 设计成带方法或私有字段的类型，结果 Caretaker 无法序列化、无法深拷贝、甚至无法安全传递。正确做法是让它成为纯数据载体：
type Memento struct {
State string
Version int
Timestamp int64
}
关键点：
-
Memento字段全部导出（首字母大写），否则外部包（包括 Caretaker）无法读取 - 不提供任何 setter 方法，也不嵌套指针或 map/slice 等可变引用——避免外部修改影响原始快照
- 如果需保存复杂状态，用
json.RawMessage或[]byte存序列化结果，而不是直接存 struct 指针
Originator 的 Save() 和 Restore() 必须严格配对
回滚失效最常见的原因是状态复制不完整。比如 Originator 内部用了 map 或切片，Save() 只浅拷贝了引用：
func (o *Originator) Save() *Memento {
return &Memento{
State: o.state, // ✅ string 是值类型，安全
Data: o.cache, // ❌ 若 cache 是 map[string]int，这里只是引用！
}
}
修复方式：
- 对 slice：用
append([]T(nil), src...)深拷贝 - 对 map：手动遍历重建新 map
- 更稳妥的做法是统一走 JSON 编解码：
json.Marshal→Memento.Payload []byte→json.Unmarshal -
Restore()必须完全覆盖当前字段，不要做“merge”或“partial update”
Caretaker 用 slice 管理历史时要注意内存泄漏
很多示例直接用 []*Memento 存所有快照，但没限制长度，长期运行后 OOM。实际使用中必须加约束：
- 设置最大保存数量（如最多 50 个），超出时用
append(history[1:], m)截断旧记录 - 若
Memento含大字段（如原始图片字节），考虑只存 diff 或用 LRU 缓存淘汰策略 - 回滚操作后，建议显式将已废弃的
Memento置为nil（虽不能强制 GC，但能减少误用）
真正容易被忽略的是：Go 中没有析构函数，一旦 Memento 被 Caretaker 持有，它的生命周期就脱离 Originator 控制——所以设计上要默认它会被长期持有，别在里面塞临时资源句柄（如 *os.File）。
