撤销操作必须保存完整状态快照而非反向函数，需对buffer、cursorpos、selection原子克隆；用deepcopy避免指针共享问题，设栈上限200并合并连续编辑，防止内存泄漏与渲染不同步。
撤销操作必须保存状态快照，不是简单存字符串
Go 里实现撤销，核心不是记录“上一步做了什么”，而是保存执行前的完整可恢复状态。很多人误以为 Undo() 只需调用一个反向函数，结果遇到结构体嵌套深、指针共享、切片底层数组被复用等问题，一撤销就 panic 或数据错乱。
- 每次执行变更操作（如插入一行、删除选区）前，用
deepcopy或手动克隆关键字段生成快照——别直接append原切片引用 - CLI 编辑器常见状态包括：
buffer（当前文本切片）、cursorPos、selection，三者必须原子性快照，否则光标位置和内容对不上 - 用
github.com/mohae/deepcopy比自己写Marshal/Unmarshal更轻量，且不依赖 JSON 标签；若已用encoding/gob做持久化，可复用同一套序列化逻辑
撤销栈不能无限增长，要设硬上限并支持合并连续编辑
用户狂敲键盘时，每字符都压栈会迅速吃光内存，尤其处理大文件时。但也不能简单限制栈长度——比如用户输入 “hello” 五个字符，应视为一次操作，而非五次独立 Undo 步骤。
- 在 CLI 编辑器中，监听
readline的事件粒度：用github.com/elves/elvish/store或自定义InputEvent类型区分 “键入”、“粘贴”、“Ctrl+K 删除整行” 等语义操作 - 设置栈容量上限（如
maxHistory = 200），超出时从栈底移除最老快照；注意用slice实现栈时避免内存泄漏——用copy覆盖再reslice，别只改len - 连续快速输入（间隔
Redo 逻辑不是 Undo 的逆过程，而是重放快照
很多人写 Redo() 试图反向执行删除→插入、移动→回退，结果逻辑爆炸。正确做法是把 Redo 当作“跳转到某个历史快照”，和 Undo 共享同一套状态加载逻辑。
- 维护两个栈：
undoStack存过去状态，redoStack存被Undo推出的状态；每次Undo()把当前状态压入redoStack，再从undoStack弹出并加载 -
Redo()只做一件事：从redoStack弹出快照，加载进当前编辑器状态——和LoadSnapshot()函数完全复用，不新增任何业务逻辑 - 一旦用户在
Undo后做了新编辑，清空redoStack；这点容易漏，导致 redo 出现“幽灵操作”
终端光标与缓冲区状态不同步是撤销最常崩的点
CLI 工具里，用户看到的光标位置（由 ANSI 序列控制）和程序内部 cursorPos 变量经常错位。撤销后只改了 buffer 和 cursorPos，但没重绘终端，看起来像没生效。
立即学习“go语言免费学习笔记（深入）”；
- 每次
Undo或Redo结束后，必须显式调用termbox.Flush()或gocui.View.Write()重绘整个编辑区，不能只靠SetCursor - 如果用了
github.com/rivo/tview，撤销后要触发app.Draw()；用github.com/charmbracelet/bubbletea则确保Model.Init()返回非 nilCmd触发重绘 - 测试时故意在长行中间撤销，观察光标是否跳到正确列数——很多 bug 只在
cursorX > terminalWidth时暴露
备忘录模式在 CLI 场景下真正的复杂点不在结构设计，而在于状态快照的边界是否干净、终端渲染是否与内存状态严格同步。这两处一松动，撤销功能就变成玄学开关。
