Go中Memento模式需用小写不可导出结构体封装状态，通过Save()返回快照、Restore()深拷贝恢复，避免指针共享和序列化；多步回退用带上限的切片管理，注意nil防御与业务校验。
Go 里怎么用 Memento 模式保存和恢复对象状态
Go 没有类、没有继承、也没有访问修饰符，直接照搬 GoF 的 Memento 模式会踩坑——比如把状态字段暴露给外部、破坏封装，或误用指针导致回滚失效。
核心做法是：用一个不可导出的结构体封装状态，只通过方法提供「快照」和「恢复」能力，且避免共享底层数据。
-
Memento类型必须定义在目标结构体同一包内，字段全小写（如state），不导出 - 生成快照用方法（如
Save()），返回值类型是该不可导出结构体的指针或值，不暴露字段名 - 恢复操作（如
Restore(m *memento)）应深拷贝关键字段，而非直接赋值指针 - 如果状态含切片、map 或 struct 嵌套，
Save()必须显式拷贝，否则后续修改会影响快照
// 示例：带状态的编辑器
type Editor struct {
content string
cursor int
}
type memento struct { // 小写，不导出
content string
cursor int
}
func (e *Editor) Save() *memento {
return &memento{
content: e.content, // string 是值类型，安全
cursor: e.cursor,
}
}
func (e *Editor) Restore(m *memento) {
e.content = m.content // 直接赋值 OK
e.cursor = m.cursor
}
为什么不用 json.Marshal 或 gob 序列化当备忘录
序列化看似通用，但实际在回滚场景下容易出问题：性能低、无法精准控制哪些字段参与、反序列化后可能丢失方法绑定或指针语义。
更关键的是，它绕过了业务逻辑校验——比如恢复时应保持 cursor ≤ len(content)，而纯字节还原不会触发任何校验。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 序列化适合持久化或跨进程传输，不适合内存中高频的“撤销/重做”
-
json会忽略非导出字段，gob虽支持，但版本变更时兼容性差 - 若结构体含
sync.Mutex、channel或func字段，序列化直接 panic - 真正需要轻量回滚时，结构体字段级拷贝 + 方法封装，既可控又快
多个状态点怎么管理：用 []*memento 还是链表
实现 Ctrl+Z 多步回退，最自然的是切片 []*memento，但要注意索引越界和内存泄漏。
- 每次
Save()后，清空“当前之后”的所有历史（即截断切片），再追加新快照 - 不要用
append(history, m)无限制增长；设上限（如 200 步），超限时copy前 N-1 个 - 避免保存大对象（如几 MB 的
[]byte）进memento，可改存 diff 或引用 ID + 外部缓存 - 不用链表——Go 没有内置链表结构，手写增加复杂度，且切片随机访问更快，更适合撤销栈语义
容易被忽略的边界：nil 指针、并发读写、零值覆盖
很多人写完 Save() 和 Restore() 就以为完工，但真实调用时经常 panic 或静默失败。
- 如果
Editor是 nil，e.Save()直接 panic；应在方法内加if e == nil { return nil }防御 - 多个 goroutine 同时调用
Save()和Restore()？memento本身是只读的，但目标对象不是线程安全的，需额外加锁或由上层协调 -
Restore(nil)不报错但什么也不做——建议在方法开头加if m == nil { return }，避免静默丢弃意图 - 如果状态字段是 map 或 slice，初始化为
nil，恢复时直接赋nil可能引发后续 panic；应在Restore中判空并初始化
备忘录真正的难点不在“怎么存”，而在“什么时候不该存”和“恢复时是否还满足业务约束”——这些没法靠模式自动解决，得靠你写在 Restore 里的那几行校验。
