Go 语言可通过结构体值拷贝、闭包或 JSON 序列化模拟备忘录模式，核心是安全保存与恢复对象状态而不破坏封装；需深拷贝避免引用污染，备忘录应不可变且字段小写，历史栈需管理索引与容量。
Go 语言没有类和继承，也不支持传统面向对象语境下的「备忘录模式」UML 实现（比如 Memento 接口 + Originator + Caretaker 三角色），但完全可以用结构体、值语义和闭包模拟出等效行为——关键是理解它要解决的问题：**安全地保存和恢复某个对象的内部状态快照，且不破坏封装**。
用结构体字段 + 值拷贝实现最简备忘录
Go 中最自然的方式是让原对象（Originator）自己提供 Save() 和 Restore() 方法，返回/接收一个只含必要字段的纯数据结构（即备忘录）。这个结构体不暴露内部逻辑，仅作序列化载体。
常见错误是直接保存指针或 map/slice 引用，导致快照被后续修改污染。
-
Save()必须做深拷贝：对map、slice、嵌套结构体手动复制，或用encoding/gob/json编解码（注意非导出字段会被忽略） - 备忘录结构体字段应全小写（如
state、version），避免外部直接访问，靠Originator控制读写权限 - 不要把备忘录设计成可变结构；它应是不可变快照，每次
Save()返回新实例
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) {
e.content = m.content
e.cursor = m.cursor
}
用切片管理历史栈：Undo/Redo 场景
当需要多步回退（Undo）和重做（Redo），备忘录需存入栈式结构。关键点是控制容量、避免内存泄漏、区分「当前态」与「快照态」。
立即学习“go语言免费学习笔记（深入）”；
典型陷阱是未清空 redo 栈：每次新操作后，用户若执行了 Undo 再输入新内容，旧的 Redo 链必须截断。
- 用两个切片：
history []editorMemento存所有已提交快照，index int指向当前有效位置（类似游标） - 每次
Save()后，截断history[index+1:]，再追加新快照，并更新index -
Undo()将index减 1 并Restore()；Redo()则加 1（需检查边界） - 为防爆内存，可限制
history最大长度，超出时从头部裁剪（history = history[1:]）
用闭包封装状态 + 备忘录工厂函数
若不想暴露结构体定义，可用闭包将状态和操作函数打包，对外只返回操作接口。这种方式更贴近「封装内部状态」的原始意图。
缺点是无法跨 goroutine 共享备忘录，且调试时难追踪字段变化。
- 工厂函数返回
Save()和Restore()闭包，共享同一份状态变量 - 备忘录本身是匿名结构字面量或 map[string]interface{}，但务必确保值拷贝
- 慎用
unsafe.Pointer或反射做「伪深拷贝」——极易出错，且失去类型安全
func NewEditor() (save func() map[string]interface{}, restore func(map[string]interface{})) {
state := map[string]interface{}{
"content": "",
"cursor": 0,
}
save = func() map[string]interface{} {
cp := make(map[string]interface{})
for k, v := range state {
cp[k] = v // 注意：此处仅浅拷贝；若 v 是 map/slice，需递归处理
}
return cp
}
restore = func(m map[string]interface{}) {
state["content"] = m["content"]
state["cursor"] = m["cursor"]
}
return save, restore
}
JSON 序列化备忘录的兼容性坑
用 json.Marshal / json.Unmarshal 管理备忘录看似方便，但实际有多个隐性约束：
- 结构体字段必须首字母大写（否则 JSON 包忽略），但这样又破坏了「内部状态封装」的设计初衷
- 时间类型、自定义类型、函数字段无法直接序列化，需实现
MarshalJSON方法 - 浮点数精度丢失、
NaN/Inf会触发错误，需预检 - 性能开销比纯结构体拷贝高约 3–5 倍，高频操作（如编辑器实时快照）慎用
真正需要跨进程/持久化时再上 JSON；单进程内状态快照，优先用结构体值拷贝。
