go中实现memento模式需为业务类型定义专属不可变快照结构体，由原对象显式深拷贝值类型字段生成，配合容量受限的环形缓冲区管理生命周期，避免反射、map或接口带来的类型不安全与内存泄漏。
Go 里怎么写一个真正可用的 Memento（不靠反射、不侵入业务）
Go 没有类和私有字段，所谓“备忘录模式”不能照搬 Java 那套——直接暴露内部状态结构体给 Memento 是危险的，但全靠反射又难调试、性能差、IDE 不友好。可行路径只有一条：让原对象自己决定哪些字段要保存，并返回一个不可变的、无指针引用的快照。
- 状态快照必须是值类型或深拷贝后的结构体，避免外部修改影响原始对象
- 不要把
Memento设计成接口，Go 里用具体结构体 + 构造函数更清晰、可验、易测试 - 别在
Memento里存方法或闭包，它只是数据容器，恢复逻辑应由原对象承担 - 示例中
Editor的Save()返回*EditorMemento，而Restore()接收该类型——不是泛型也不是空接口，类型明确才能防误用
为什么不能用 struct{} 或 map[string]interface{} 做 Memento
看似灵活，实则埋雷。用 map[string]interface{} 保存状态会导致类型信息丢失，恢复时无法做字段校验；用 struct{} 则根本没法存任何东西。更严重的是：它们绕过了 Go 的类型系统，编译期无法发现字段名拼错、类型不匹配等问题。
-
map[string]interface{}序列化后字段顺序不确定，json.Marshal可能打乱键序，影响可读性与 diff - 恢复时需手动类型断言，一旦字段类型变更（比如
int改成int64），运行时报panic: interface conversion - IDE 无法跳转、补全、重命名字段，重构成本陡增
- 正确做法是为每个需要备忘的类型定义专属
EditorMemento结构体，字段一一对应且导出
Save() 和 Restore() 必须成对管理内存与生命周期
Go 没有析构函数，Memento 对象如果包含指针或大字段（比如 []byte、map），不加控制地反复 Save() 会悄悄吃光内存。关键不是“能不能存”，而是“存多久、谁负责释放”。
- 每次
Save()应返回新分配的结构体，而不是复用旧实例（避免浅拷贝污染） - 如果状态含切片或 map，务必显式深拷贝：
copy(dst, src)或for k, v := range src { dst[k] = v } - 不要在
Memento里存sync.Mutex、chan、func等不可序列化/不可复制类型，否则恢复必 panic - 示例中
EditorMemento只含content string和cursor int，这两个都是值类型，天然安全
实际用在 Undo/Redo 时，Memento 列表怎么管才不泄漏
用户狂按 Ctrl+Z，[]*EditorMemento 会越积越多。不限制长度，程序跑几天就 OOM；全靠上层调用方手动清理，又容易漏掉。最简方案是内置容量上限 + 覆盖策略，而非暴露底层切片。
立即学习“go语言免费学习笔记（深入）”；
- 用环形缓冲区（
type UndoStack struct { data []*EditorMemento; cap, head, len int }）比append更可控 - 不要让用户直接操作
stack.data，提供Push(m *EditorMemento)和Pop() *EditorMemento封装 - 如果
Push触发覆盖，被挤掉的Memento实例不再被引用，GC 自动回收——前提是没其他地方偷偷 hold 住指针 - 注意：
UndoStack本身不应持有对Editor的引用，否则形成循环引用阻碍 GC
真正麻烦的从来不是“怎么存状态”，而是“哪些字段该存、哪些不该存、存了之后谁来保证它不会被意外改写”。Go 的简洁性在这里反而是优势：没有访问修饰符，就老老实实用结构体字段可见性 + 显式拷贝来划清边界。别的都好说，只要快照一出来就是个干净的值，那就稳了一半。
