Go中备忘录模式需用非导出结构体封装快照、接口作类型标记，发起者控制Save/Restore；只备份业务字段，避免指针/map共享；限制栈长度并置空引用助GC；测试用reflect.DeepEqual验证隔离性。
备忘录模式在 Go 里没有语言原生支持，得靠结构体 + 接口手动搭
Go 没有类、没有继承、也没有 private 字段，所以经典 OOP 里的备忘录模式（Memento）不能照搬。核心矛盾在于：备忘录对象必须能读取发起者（Originator）的内部状态，但又不能暴露这些字段给外部。解决办法是让发起者自己负责创建和恢复备忘录，用结构体封装快照，用接口约束访问边界。
-
Memento接口只声明一个空方法（比如restore()），实际不提供读取能力，纯作类型标记 - 真正保存状态的结构体（如
editorMemento）定义为发起者包内非导出类型，外部无法直接访问字段 - 发起者提供
Save()和Restore(m *editorMemento)方法，把状态读写逻辑收在内部
别把状态字段全塞进备忘录结构体——按需快照才是关键
常见错误是把整个 struct 复制一遍，比如把 *Editor 所有字段都深拷贝进 memento。这不仅浪费内存，还容易因指针或 map 引用导致恢复时状态污染。真实场景中，你往往只需要记录“可撤销”的那部分变化，比如编辑器的文本内容、光标位置，而不是缓存池、日志句柄这些运行时资源。
- 只备份业务相关字段：比如
content string、cursor int，而非logger *zap.Logger - 避免直接嵌套指针或 map：用
copy()或json.Marshal/Unmarshal做浅层隔离（简单场景够用） - 如果状态含时间戳或随机 ID，考虑是否要忽略——多数撤销操作不需要还原生成时间
用 slice 管理备忘录栈时，注意容量膨胀和 GC 压力
实现撤销/重做功能时，习惯性用 []*memento 存历史，但没设上限就会越积越多。更隐蔽的问题是：只要某个 memento 还被 slice 引用，它引用的所有对象（比如大字符串、字节切片）都无法被 GC 回收。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 加长度限制：比如最多存 200 个快照，超出就
memos = memos[1:]丢弃最老的 - 恢复后主动清空无用引用：比如
memos = memos[:len(memos)-1]后，显式置空末尾元素（memos[len(memos)-1] = nil）有助于 GC - 对超大文本编辑场景，考虑只存 diff 而非全量快照，用
github.com/yuin/goldmark/util这类轻量 diff 工具
测试备忘录恢复逻辑时，最容易漏掉指针语义陷阱
Go 的 struct 字面量赋值默认是值拷贝，但字段里有指针（比如 *bytes.Buffer）或 map 就会共享底层数据。测试时看着 “恢复成功”，实际只是改了同一块内存。
立即学习“go语言免费学习笔记（深入）”；
- 写测试用例时，恢复后立刻修改原始字段，再检查备忘录里对应值是否不变
- 避免在
Save()中直接赋值m.content = e.content（若content是*string） - 用
reflect.DeepEqual比较恢复前后状态，比==更可靠 - 示例：
func TestRestoreIsolation(t *testing.T) { e := &Editor{content: "hello"} m := e.Save() e.content = "world" // 修改原对象 e.Restore(m) if e.content != "hello" { // 必须是 hello，不是 world t.Fatal("restore failed: content not isolated") } }
真正难的不是存和取，是怎么让“恢复”这件事不悄悄牵扯其他变量。每次加新字段到状态结构体，都要问一句：这个字段的拷贝方式，会不会在某次 Restore 后变成两个对象共用同一片内存。
