go中备忘录模式关键在于安全可控地捕获恢复状态，需用私有结构体+方法封装、避免指针引用陷阱，深拷贝优先选gob，还需考虑内存管理与清理时机。
Go 语言本身没有类、继承和访问修饰符，因此直接照搬传统面向对象语言（如 Java）的备忘录模式实现会显得生硬甚至误导。真正的关键不是“怎么写个 Memento 结构体”，而是「如何安全、可控地捕获和恢复某个对象的内部状态」——这在 Go 中更依赖值语义、深拷贝策略和封装边界的设计。
为什么不能直接用 struct 做 Memento？
Go 的 struct 默认是值传递，看似天然支持“快照”，但实际中容易踩坑：
- 如果结构体里含指针、
map、slice、chan或func字段，直接赋值只会复制引用，后续修改会影响“备忘录”内容 - 未导出字段（小写开头）无法被外部包读取，而备忘录通常需要跨包保存/恢复，必须靠方法暴露，而非字段直取
- Go 不支持私有构造函数，没法阻止用户手动 new 一个
Memento并篡改其内容
用嵌入+私有字段+构造方法模拟受控状态捕获
核心思路：把状态快照逻辑收进原对象的方法里，返回一个只读视图；恢复也由原对象自己完成，不暴露内部字段。
示例场景：一个简单的文本编辑器状态（内容 + 光标位置）
立即学习“go语言免费学习笔记（深入）”；
type Editor struct {
content string
cursor int
}
type editorMemento struct { // 小写开头，包内私有
content string
cursor int
}
func (e *Editor) Save() *editorMemento {
return &editorMemento{
content: e.content,
cursor: e.cursor,
}
}
func (e *Editor) Restore(m *editorMemento) {
if m == nil {
return
}
e.content = m.content
e.cursor = m.cursor
}
注意：editorMemento 是包内类型，外部无法构造或修改；Save() 返回指针是为了避免大对象拷贝，且调用方无法修改其字段（没提供 setter）。
需要深拷贝时，用 encoding/gob 或 json（慎选）
当状态含 map 或嵌套结构，且必须保证完全隔离时，手动复制太易错。此时可借助序列化：
-
encoding/gob是 Go 原生二进制格式，性能好、支持私有字段（只要在同一包），适合内部状态快照 -
json可读性强，但只序列化导出字段，且 float/int 类型可能失真，不推荐用于精确状态保存 - 避免用
reflect.DeepCopy—— Go 官方不提供该函数，第三方库行为不一，运行时开销大
使用 gob 的最小可行示例：
import "encoding/gob"
func (e *Editor) SaveDeep() []byte {
var buf bytes.Buffer
enc := gob.NewEncoder(&buf)
enc.Encode(struct {
Content string
Cursor int
}{e.content, e.cursor})
return buf.Bytes()
}
func (e *Editor) RestoreDeep(data []byte) {
var state struct {
Content string
Cursor int
}
buf := bytes.NewReader(data)
dec := gob.NewDecoder(buf)
dec.Decode(&state)
e.content = state.Content
e.cursor = state.Cursor
}
别忽略生命周期和内存管理
备忘录不是免费的。每个 Save() 都可能分配内存，尤其在高频编辑场景下：
- 不要无限制缓存所有历史状态，考虑用栈+最大长度限制（如 LRU）
- 如果状态很大（比如含图像数据），优先保存差异（diff）而非全量快照
- 避免在 goroutine 中长期持有旧
*editorMemento，它可能阻止底层数据被 GC
真正难的从来不是“怎么存”，而是“什么时候删”和“谁负责删”。Go 没有析构函数，得靠显式清理或带 TTL 的 map。
