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”，而是“能不能安全存取状态”。下面是一个生产可用的简化版：

// 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，但服务端状态已变。备忘录管不了外部副作用，它只负责对象内部字段的来回搬运。这点不厘清，越优化越错。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。