不该用 Stack 做撤销逻辑，因其继承 Vector 导致无谓同步拖慢性能且违背组合优于继承原则；应使用 ArrayDeque，用 push()/pop() 严格遵循 LIFO，封装操作对象并快照必要状态。
Java 的 Stack 类不推荐用于新代码，它既是遗留类又存在线程安全与继承设计缺陷；真正适合撤销操作的是 ArrayDeque。
为什么不该用 Stack 做撤销逻辑
Stack 继承自 Vector，所有方法都加了 synchronized，但撤销操作通常在单线程 UI 或命令队列中执行，无谓的同步拖慢性能；更关键的是，它违背“组合优于继承”原则——你只需要后进先出行为，不需要 Vector 的全部列表能力（比如 elementAt()、随机访问）。JDK 文档明确建议用 ArrayDeque 替代。
用 ArrayDeque 实现撤销栈的正确姿势
把每次可撤销的操作封装为对象（如 Command 接口），入栈用 push()，撤销用 pop()，清空用 clear()。注意：不要用 add() 或 offer()，它们会从尾部添加，破坏 LIFO 语义。
-
push()等价于addFirst()，确保最新操作在栈顶 -
pop()等价于removeFirst()，严格按顺序弹出 - 初始化时指定容量（如
new ArrayDeque(50)）避免频繁扩容 - 撤销前务必检查
isEmpty()，否则pop()抛NoSuchElementException
撤销操作中容易被忽略的状态管理
单纯存操作对象不够——比如文本编辑器撤销“删除选中文本”，必须同时保存被删内容和光标位置。常见错误是只存动作类型（"DELETE"），没存上下文数据。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
示例结构：
class DeleteCommand implements Command {
String deletedText;
int cursorPos;
// 构造时捕获当前状态
DeleteCommand(String text, int pos) {
this.deletedText = text;
this.cursorPos = pos;
}
void execute() { /* 恢复文本 + 移动光标 */ }
}另外，撤销栈本身应作为业务对象的成员变量，而非静态或全局单例，否则多文档场景下状态互相污染。
真正麻烦的不是“怎么压栈弹栈”，而是“哪些状态要快照”和“快照粒度是否合理”——一次用户击键就存一个命令？还是合并成复合命令？这取决于响应速度与内存开销的权衡，ArrayDeque 只负责容器，逻辑得你亲手拧紧。
