如何使用Golang实现备忘录模式_Golang备忘录模式实现与优化方法

go无法直接实现经典备忘录模式，因缺乏访问控制导致封装失效；实际采用非导出memento结构体+包级作用域限制，由Originator提供Save/Restore方法，Caretaker仅存储指针。

Go 语言没有类和继承，也不支持传统面向对象意义上的备忘录模式（Memento Pattern）实现，但可以用结构体、接口和闭包模拟其核心能力：**安全地捕获和恢复对象内部状态，且不破坏封装**。

为什么 Go 中不能直接套用经典备忘录模式

经典备忘录模式依赖三个角色：Memento（只读快照）、Originator（拥有状态并创建/恢复）、Caretaker（持有但不修改 Memento）。Go 没有访问控制修饰符（如 private），无法强制 Caretaker 无法访问 Memento 内部字段——这会让“封装性”形同虚设。

所以实际做法是：

• 把 Memento 设计为不可导出字段 + 不暴露 setter/getter 的结构体，靠包级作用域限制访问
• 让 Originator 提供 Save() 和 Restore(m *memento) 方法，所有状态操作收口在它内部
• Caretaker 只负责存储 *memento，绝不解引用或强转

用结构体+接口实现可恢复的备忘录

关键不是“像不像 uml”，而是“能不能安全存取状态”。下面是一个生产可用的简化版：

立即学习“go语言免费学习笔记（深入）”；

// originator.go package memo  type editor struct { 	content String 	cursor  int }  func NewEditor() *editor { 	return &editor{} }  func (e *editor) Insert(text string) { 	e.content += text 	e.cursor = len(e.content) }  func (e *editor) UndoableSave() *memento { 	// 返回一个仅本包可解构的快照 	return &memento{ 		content: e.content, 		cursor:  e.cursor, 	} }  func (e *editor) Restore(m *memento) { 	e.content = m.content 	e.cursor = m.cursor }  // memento 是非导出类型，外部无法构造或修改 type memento struct { 	content string 	cursor  int }

注意：memento 小写开头，外部包即使拿到指针也无法访问字段——这是 Go 唯一能依赖的“封装机制”。

避免深拷贝陷阱：何时该用 json.RawMessage 或 unsafe？

如果 editor 状态非常大（比如含切片、嵌套 map、大字符串），每次 Save() 都做完整结构拷贝会浪费内存和 CPU。

优化思路：

• 对纯值类型（int、string、小结构体），直接赋值即可，Go 自动 copy
• 若状态含 []byte 或 map[string]Interface{}，且你确定不会在恢复前修改原数据，可考虑用 json.RawMessage 序列化后暂存——但要加注释说明“此 memento 依赖原始数据生命周期”
• 绝不要为性能过早引入 unsafe；Go 的 GC 对短生命周期小对象很友好，先压测再优化

例如，需要序列化的场景可以这样扩展：

func (e *editor) SaveAsJSON() json.RawMessage { 	state := struct { 		Content string `json:"content"` 		Cursor    int    `json:"cursor"` 	}{e.content, e.cursor} 	b, _ := json.Marshal(state) 	return b }  func (e *editor) RestoreFromJSON(data json.RawMessage) { 	var state struct { 		Content string `json:"content"` 		Cursor    int    `json:"cursor"` 	} 	json.Unmarshal(data, &state) 	e.content = state.Content 	e.cursor = state.Cursor }

多状态管理与撤销栈的常见误用

很多人以为“实现一个 Memento 就等于有了 undo”，其实真正难的是状态管理和边界控制：

• 不控制快照数量，UndoStack 无限增长 → OOM；应设置最大长度（如 100），用 slice + append + copy 实现循环缓冲
• 在 Restore() 后没清空“重做栈”，导致用户 redo 时跳回错误状态 → 必须在每次 Restore() 后重置 redo 栈
• 异步操作（如 goroutine 中保存快照）和主线程恢复冲突 → 所有状态变更和快照操作必须串行，推荐用 chan 或 sync.Mutex 保护

最简撤销栈示意：

type Editor struct { 	undoStack []*memento 	redoStack []*memento 	*editor // 内嵌 }  func (e *Editor) Save() { 	m := e.UndoableSave() 	e.undoStack = append(e.undoStack, m) 	if len(e.undoStack) > 100 { 		e.undoStack = e.undoStack[1:] 	} 	e.redoStack = e.redoStack[:0] // 清空 redo }

真正容易被忽略的，是“状态是否真的可逆”——比如你保存了文件路径，但文件已被删除；或者保存了网络请求 ID，但服务端状态已变。备忘录管不了外部副作用，它只负责对象内部字段的来回搬运。这点不厘清，越优化越错。