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