golang如何实现备忘录模式_golang备忘录模式实现方案-Golang-PHP中文网

go中备忘录模式需用非导出结构体封装快照、接口作类型标记，发起者控制save/restore；只备份业务字段，避免指针/map共享；限制栈长度并置空引用助gc；测试用reflect.deepequal验证隔离性。

golang如何实现备忘录模式_golang备忘录模式实现方案

备忘录模式在 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 就会共享底层数据。测试时看着 “恢复成功”，实际只是改了同一块内存。

写测试用例时，恢复后立刻修改原始字段，再检查备忘录里对应值是否不变
避免在 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 后变成两个对象共用同一片内存。