Go中备忘录模式应避免reflect深拷贝，改用显式定义Memento结构体+手动映射关键状态；支持Undo/Redo需双栈管理，JSON序列化适用于持久化，保存时机须匹配用户意图边界。
Go 语言没有类、继承和构造函数，也不支持直接保存对象完整状态快照（比如 reflect 深拷贝开销大且不可靠），所以「经典备忘录模式」在 Go 里不能照搬 UML 类图实现——但你可以用更轻量、更符合 Go 风格的方式达成相同目标：安全地保存和恢复关键状态。
为什么不用 reflect.DeepCopy 做备忘录
很多人第一反应是用 reflect 或第三方深拷贝库来复制整个结构体。这在 Go 里问题很多：
-
reflect拷贝无法处理未导出字段（private字段直接被跳过） - 含
sync.Mutex、channel、func类型的结构体 panic 或静默失败 - 性能差，每次保存都触发大量反射操作，不适合高频回滚场景
- 无法控制哪些字段该存、哪些该忽略（比如时间戳、ID 等运行时字段不该回滚）
推荐做法：显式定义 Memento 结构体 + 手动状态映射
把「需要回滚的状态」明确抽成一个独立、可序列化的结构体，由业务代码决定保存什么、恢复什么。这是 Go 中最可控、最易测试的方式。
示例：一个简单的文本编辑器状态管理
立即学习“go语言免费学习笔记（深入）”；
type Editor struct {
content string
cursor int
undoStack []*EditorMemento
}
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 {
e.content = m.content
e.cursor = m.cursor
}
}
func (e *Editor) Undo() {
if len(e.undoStack) == 0 {
return
}
last := e.undoStack[len(e.undoStack)-1]
e.undoStack = e.undoStack[:len(e.undoStack)-1]
e.Restore(last)
}
// 使用示例：
// editor := &Editor{content: "hello", cursor: 3}
// editor.Save() // → 生成快照
// editor.content = "hello world"
// editor.Undo() // → 回滚到 "hello"
如何支持多次连续回滚（Undo/Redo）
只用一个栈只能做 Undo；要支持 Redo，得维护两个栈：undoStack 和 redoStack，且每次 Undo 后要把当前状态推入 redoStack。
- 每次调用
Save()前，先清空redoStack（用户新输入后，之前的 Redo 失效） -
Undo()把当前状态存进redoStack，再从undoStack弹出并恢复 -
Redo()反向操作：弹出redoStack并推入undoStack，再恢复 - 注意：
Save()应该在真正修改状态前调用（比如用户敲字前快照），否则会漏掉中间态
JSON 序列化备忘录适用于跨进程/持久化场景
如果需要把备忘录存到文件或发给前端，用 json.Marshal 比直接传指针更安全：
type EditorMemento struct {
Content string `json:"content"`
Cursor int `json:"cursor"`
}
func (e *Editor) SaveToJSON() ([]byte, error) {
m := &EditorMemento{
Content: e.content,
Cursor: e.cursor,
}
return json.Marshal(m)
}
func (e *Editor) RestoreFromJSON(data []byte) error {
var m EditorMemento
if err := json.Unmarshal(data, &m); err != nil {
return err
}
e.content = m.Content
e.cursor = m.Cursor
return nil
}
注意字段必须是导出的（首字母大写），且类型要 JSON 可序列化。这种方案天然规避了指针、闭包、未导出字段等问题，也方便调试和日志记录。
真正容易被忽略的是状态保存的时机和粒度——不是“每次赋值都 Save”，而是“在用户意图明确的边界点 Save”，比如执行完一次 ReplaceAll、完成一次拖拽、提交表单前。否则栈会爆炸，且语义混乱。
