php命令模式撤销栈用两个数组实现：$history存已执行命令，$redostack存被撤销命令；新命令入$history前清空$redostack，undo时从$history弹出并调用undo()后压入$redostack，redo则反向操作；命令须在execute()前捕获并保存全部上下文（如原文、位置、长度），不可依赖运行时外部状态。
PHP中命令模式的撤销栈怎么设计
撤销重做不是靠保存整个对象状态快照，而是记录“做了什么”，再反向执行。核心是把每个可撤销操作封装成独立的Command类，实现统一的execute()和undo()接口。栈结构用两个array就够了：一个存已执行的命令（$history），一个存被撤销掉的命令（$redoStack）。
关键点在于：命令对象必须能保存执行所需的全部上下文——比如编辑文本时，不能只记“替换”，还得记原内容、位置、新内容；删除行时得记哪几行、删前内容。否则undo()会失效。
-
$history只在execute()成功后才push()，避免半截操作污染栈 - 每次
undo()从$history弹出，调用其undo()，再压入$redoStack -
redo()则从$redoStack弹出，调用execute()，再压回$history - 执行新命令时清空
$redoStack——这是用户最常漏掉的逻辑，否则重做会错乱
命令类必须保存哪些数据才能可靠undo
不保存原始数据，undo()就是空中楼阁。比如一个TextReplaceCommand，至少要存：$textBefore、$textAfter、$offset、$length。如果只存$newText，那undo()根本不知道该换回去什么。
常见错误是让命令依赖外部对象状态（如直接传入一个Document引用并在undo()里读它的当前值），这会导致撤销时取到的是最新值而非操作前的值。
- 所有用于还原的数据必须在
execute()开始前捕获并存为命令属性 - 避免在
undo()里调用外部方法获取“当前状态”——它已经变了 - 对数组或对象属性的修改，建议深拷贝（
serialize/unserialize或json_encode/decode）原始值，而不是引用 - 如果操作涉及数据库，命令应包含
id和变更前的字段快照，而不是依赖SELECT NOW()
PHP数组栈的性能与内存注意事项
用array_push()/array_pop()模拟栈没问题，但要注意：PHP数组是哈希表实现，array_shift()或中间删除会触发重排，O(n)开销。撤销栈只用末尾进出，所以坚持用push/pop就行。
真正的问题是内存。如果每个命令都存一份大文本或图像二进制，100次操作就可能吃掉几十MB。生产环境必须加限制：
- 设置最大历史长度（如
MAX_HISTORY = 50），超限时array_shift()丢弃最早命令 - 对大内容做摘要（如
md5($content)）+ 外部存储，命令只存摘要和ID - 敏感操作（如删除）的
$textBefore可设为null，undo()提示“内容已不可恢复”，避免存储风险数据 - 注意
__destruct()里清理资源（如临时文件句柄），否则命令对象长期驻留会泄漏
如何处理命令间依赖与并发冲突
PHP本身无状态，但Web请求是离散的。用户A在页面改了第3行，用户B同时删了第2行——这时A的撤销命令若还按原偏移操作，就会错位。命令模式解决不了协同编辑问题，它只保证单用户本地操作链的可逆性。
真实场景中，撤销栈必须绑定到具体会话（session）或前端实例（如用client_id隔离），不能全局共享。另外，如果命令执行失败（如DB事务回滚），不要把它推进$history，否则后续undo()会尝试撤销一个根本没生效的操作。
- 每个用户会话维护独立的
CommandHistory实例，别用static变量共享 - 命令的
execute()应返回布尔值或抛异常，失败时不更新栈 - 前端需同步维护自己的操作序列号（
seq_no），和服务端比对，跳过已失效的撤销指令 - 对时间敏感操作（如定时任务触发的命令），
undo()应检查是否已过期，避免误恢复过期状态
Command接口，而是判断哪些操作值得封装、哪些数据必须捕获、以及什么时候该主动截断历史——这些没法靠模式自动解决。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
