只要是寫過編輯器類軟件的人幾乎都躲不開同一個(gè)話題撤銷 / 重做。文本輸入框刪錯(cuò)字要能退回來畫圖工具手滑畫歪一筆要能還原模型編輯器里誤刪了一個(gè)節(jié)點(diǎn)總得讓人反悔。QUndoStack 就是 Qt 專門為這類場(chǎng)景提供的一套完整框架它把一個(gè)看似簡(jiǎn)單、做起來全是細(xì)節(jié)的撤銷棧抽象成了命令模式下的標(biāo)準(zhǔn)實(shí)現(xiàn)。這篇文章會(huì)從需求拆解、核心原理、具體落地再到常見坑位把你需要用到的部分一次講清楚。適用的人群很寬剛接觸 Qt 的開發(fā)者可以把它當(dāng)作入門指南寫過一段時(shí)間 C 但始終在自己攢撤銷邏輯的朋友也能在這里找到系統(tǒng)化的替代方案。1. 為什么要用 QUndoStack撤銷 / 重做的需求拆解1.1 撤銷 / 重做看似簡(jiǎn)單真正落地時(shí)問題一堆表面上看撤銷 / 重做就是記住上一步然后還原。很多新手的第一反應(yīng)是存快照每次操作前把整個(gè)文檔復(fù)制一份撤銷時(shí)把舊版本覆蓋回去。這個(gè)思路在數(shù)據(jù)量小的時(shí)候確實(shí)能跑但一旦文檔變大比如一個(gè)帶幾千個(gè)圖元的矢量圖、一份多頁(yè)表格或者一段幾十萬字的文本每次快照的內(nèi)存開銷和拷貝耗時(shí)都會(huì)迅速失控。更麻煩的是快照方案很難回答用戶做了三次修改之后只想撤銷中間那一次這類需求你只能無腦回退整個(gè)版本而不是精準(zhǔn)撤銷某個(gè)命令。另一種常見思路是反向操作比如插入了一段文字撤銷時(shí)再?gòu)耐晃恢脛h掉。這個(gè)方案比快照聰明但依然有死角有些操作天然不可逆比如把圖片壓縮、把文件覆蓋、執(zhí)行一次批量替換你根本沒有足夠的反向信息把它恢復(fù)如初。所以真正健壯的撤銷體系必須讓操作自己攜帶undo和redo兩套邏輯這也正是 QUndoStack 的命令模式設(shè)計(jì)。1.2 自己維護(hù)撤銷棧的三個(gè)典型痛點(diǎn)我見過不少項(xiàng)目在早期都是自己定義結(jié)構(gòu)體、用兩個(gè) QList 或者 std::vector 硬寫撤銷邏輯寫到最后幾乎都會(huì)遇到同樣的三類問題。第一類是狀態(tài)與數(shù)據(jù)綁死。最常見的寫法是每次修改數(shù)據(jù)前先手動(dòng)把舊值塞進(jìn)一個(gè)列表然后等撤銷時(shí)再取出來賦值回去。這種代碼遇到多個(gè)控件同時(shí)修改同一個(gè)模型的場(chǎng)景立刻亂套因?yàn)槟愫茈y判斷當(dāng)前這個(gè)舊值到底對(duì)應(yīng)哪個(gè)狀態(tài)節(jié)點(diǎn)。第二類是臟標(biāo)記管理混亂。正規(guī)一點(diǎn)的編輯器都會(huì)在標(biāo)題欄顯示未保存的狀態(tài)撤銷到初始狀態(tài)時(shí)要把這個(gè)標(biāo)記清掉。自己寫撤銷棧的人通常是在每個(gè)命令里手動(dòng)維護(hù)一個(gè) bool改來改去很容易漏掉某個(gè)分支最后出現(xiàn)文檔明明恢復(fù)原樣卻還提示未保存的詭異表現(xiàn)。第三類是多窗口協(xié)作基本沒法做。一個(gè)多文檔編輯器往往要同時(shí)打開好幾個(gè)文件如果每個(gè)文件各自維護(hù)一套撤銷邏輯那撤銷到底撤銷哪個(gè)窗口是全局只允許一個(gè)活動(dòng)窗口能撤銷還是每個(gè)窗口互相獨(dú)立沒有統(tǒng)一抽象的時(shí)候這個(gè)問題會(huì)被你以各種丑陋的方式臨場(chǎng)處理。QUndoStack 之所以值得專門寫一篇就是因?yàn)樗焉厦孢@三塊都兜住了命令對(duì)象里既有數(shù)據(jù)又有行為stack 自帶干凈狀態(tài)標(biāo)記QUndoGroup 還能把多個(gè)文檔的撤銷棧組織在一起統(tǒng)一管理。2. QUndoStack 核心設(shè)計(jì)思路拆解2.1 命令模式把一次操作封裝成一個(gè)對(duì)象QUndoStack 的設(shè)計(jì)藍(lán)本來自經(jīng)典的設(shè)計(jì)模式——命令模式。它不像快照那樣保存結(jié)果而是把產(chǎn)生結(jié)果的動(dòng)作保存下來。每個(gè)動(dòng)作在代碼里對(duì)應(yīng)一個(gè) QUndoCommand 的子類這個(gè)子類至少要實(shí)現(xiàn)兩個(gè)虛函數(shù)class MyCommand : public QUndoCommand { public: void undo() override { // 撤銷這個(gè)操作時(shí)執(zhí)行什么 } void redo() override { // 重新執(zhí)行或者首次執(zhí)行這個(gè)操作時(shí)執(zhí)行什么 } };這里有個(gè)很多人一開始會(huì)繞不清的點(diǎn)reda() 不只是重做時(shí)調(diào)用它同時(shí)也是命令第一次被 push 進(jìn)棧時(shí)立刻執(zhí)行的那個(gè)入口。換句話說當(dāng)你把一個(gè)命令交給 QUndoStack 時(shí)stack 會(huì)先調(diào)用這個(gè)命令的 redo() 把操作真正落到數(shù)據(jù)上然后再把它放進(jìn)撤銷棧。這樣設(shè)計(jì)的好處是無論第一次執(zhí)行還是 n 次重做走的是同一條代碼路徑邏輯天然統(tǒng)一。命令對(duì)象里保存的應(yīng)當(dāng)是執(zhí)行和撤銷所需的全部信息。比如移動(dòng)一個(gè)圖元你要么保存圖元移動(dòng)前后的兩個(gè)坐標(biāo)要么保存圖元的 id 加新的位置這樣 undo 才能找到它并把坐標(biāo)改回去。QUndoCommand 的構(gòu)造參數(shù)里可以傳入一段文本描述比如移動(dòng)圖元插入表格這段文本不只是給人看的它直接出現(xiàn)在菜單按鈕的文案里這個(gè)后面會(huì)講。2.2 雙棧模型undo 棧、redo 棧與索引QUndoStack 內(nèi)部實(shí)際上維護(hù)了兩個(gè)邏輯棧一個(gè)裝已經(jīng)執(zhí)行、可以被撤銷的命令另一個(gè)裝被撤銷過、可以重做的命令。你按下撤銷它從 undo 棧頂彈出一個(gè)命令并調(diào)用它的 undo()然后把命令扔進(jìn) redo 棧按下重做則是反著來。兩個(gè)棧之外還有一個(gè)關(guān)鍵的索引狀態(tài)它是理解 QUndoStack 的鑰匙?？梢园衙铌?duì)列想象成一條時(shí)間軸當(dāng)前索引表示現(xiàn)在處于歷史節(jié)點(diǎn)的哪個(gè)位置。每次 push 新命令index 就前進(jìn)一格同時(shí) redo 棧被整體清空——因?yàn)闅v史已經(jīng)被新的分支配改變了之前的重做路徑不再有效。與之相關(guān)的幾個(gè)查詢接口都很常用index()返回當(dāng)前索引位置。count()返回命令隊(duì)列總長(zhǎng)度undo 棧長(zhǎng)度 redo 棧長(zhǎng)度。undoText()/redoText()返回下一步撤銷 / 重做操作所對(duì)應(yīng)的命令文本。canUndo()/canRedo()判斷當(dāng)前是否有可撤銷 / 可重做的命令。這些接口是給你做 UI 聯(lián)動(dòng)用的。比如按鈕的 enabled 狀態(tài)、菜單里的動(dòng)態(tài)文案撤銷 移動(dòng)圖元都可以直接從這幾個(gè)方法里取得不需要自己額外記錄狀態(tài)。2.3 命令的所有權(quán)與生命周期規(guī)則QUndoStack 有個(gè)內(nèi)存管理規(guī)則剛開始容易踩通過push()傳入的命令其所有權(quán)會(huì)轉(zhuǎn)移給 stack由 stack 負(fù)責(zé)在合適的時(shí)候刪除。你不需要手動(dòng)delete也絕不能在 push 之后繼續(xù)持有并使用那個(gè)裸指針除非你明確知道 stack 還沒清理它。對(duì)于一段代碼來說這意味著你應(yīng)當(dāng)把命令對(duì)象當(dāng)作一次性消耗品。正確寫法是QUndoStack *stack new QUndoStack(this); auto *cmd new EditTextCommand(m_model, m_id, oldText, newText); stack-push(cmd);如果你還持有另一個(gè)cmd的引用后續(xù)一旦用戶撤銷、重做或者 stack 達(dá)到 undo 上限Qt 會(huì)把不再需要的命令從內(nèi)存中清掉那個(gè)引用就成了懸空指針。我見過一些代碼為了復(fù)查命令狀態(tài)而保存命令指針結(jié)果偶發(fā)崩潰排查半天才發(fā)現(xiàn)是緩存了 stack 自己管理的對(duì)象。3. 實(shí)操落地為你的應(yīng)用接入一套完整撤銷體系3.1 兩種典型命令對(duì)象的寫法以圖形編輯器為例子最常見的兩個(gè)操作是添加圖元和移動(dòng)圖元。添加圖元的命令可以這樣寫class AddItemCommand : public QUndoCommand { public: AddItemCommand(ShapeModel *model, const ShapeItem item, QUndoCommand *parent nullptr) : QUndoCommand(QStringLiteral(添加圖元), parent) , m_model(model) , m_item(item) { } void undo() override { m_model-removeItem(m_item); } void redo() override { m_model-addItem(m_item); } private: ShapeModel *m_model; ShapeItem m_item; };這個(gè)命令保存了模型指針和完整的圖元數(shù)據(jù)。redo 時(shí)把它加進(jìn)去undo 時(shí)把它刪掉。關(guān)鍵的細(xì)節(jié)是m_model 指針必須指向一個(gè)在命令生命周期內(nèi)始終有效的對(duì)象。如果模型隨著文檔關(guān)閉而銷毀而命令棧還沒清空把舊的 AddItemCommand 留著繼續(xù)用就出問題了。這一點(diǎn)后面避坑部分會(huì)重點(diǎn)展開。移動(dòng)圖元命令稍微復(fù)雜一點(diǎn)它牽扯到一個(gè)重要機(jī)制命令合并。用戶用鼠標(biāo)拖動(dòng)一個(gè)圖元時(shí)鼠標(biāo)通常會(huì)產(chǎn)生幾十上百個(gè)移動(dòng)動(dòng)作如果每個(gè)移動(dòng)事件都塞進(jìn)一個(gè)獨(dú)立命令撤銷一次只回退幾個(gè)像素用戶會(huì)崩潰。合理的做法是讓同一次拖動(dòng)產(chǎn)生的所有移動(dòng)合并成一個(gè)命令。class MoveItemCommand : public QUndoCommand { public: enum { CommandId 1024 }; MoveItemCommand(ShapeModel *model, int itemId, const QPointF from, const QPointF to, QUndoCommand *parent nullptr) : QUndoCommand(QStringLiteral(移動(dòng)圖元), parent) , m_model(model), m_itemId(itemId) , m_from(from), m_to(to) { } int id() const override { return CommandId; } bool mergeWith(const QUndoCommand *other) override { auto *cmd static_castconst MoveItemCommand *(other); if (cmd-m_itemId ! m_itemId || cmd-m_model ! m_model) return false; // 把上一次的終點(diǎn)作為新命令的整體終點(diǎn) m_to cmd-m_to; return true; } void undo() override { m_model-setItemPos(m_itemId, m_from); } void redo() override { m_model-setItemPos(m_itemId, m_to); } private: ShapeModel *m_model; int m_itemId; QPointF m_from; QPointF m_to; };mergeWith 的邏輯是當(dāng)新命令的 id 與棧頂命令相同并且操作對(duì)象也一致時(shí)把新命令的信息合并進(jìn)舊命令然后返回 true這樣新命令就不會(huì)作為獨(dú)立節(jié)點(diǎn)入棧了。on r拖動(dòng)場(chǎng)景里第一次 move 事件產(chǎn)生的命令作為起點(diǎn)后續(xù)每一次 move 都嘗試合并最終保留了起點(diǎn)和終點(diǎn)撤銷一次就能讓圖元回到拖動(dòng)前的位置。3.2 push 命令的正確時(shí)機(jī)與撤銷棧的配套設(shè)置命令定義好之后業(yè)務(wù)代碼里的調(diào)用方式很直接QUndoStack *m_stack new QUndoStack(this); m_stack-setUndoLimit(100); // 最多支持 100 步撤銷防止內(nèi)存膨脹 void addItem() { ShapeItem item createItemByUserInput(); auto *cmd new AddItemCommand(m_model, item); m_stack-push(cmd); // push 會(huì)自動(dòng)執(zhí)行 redo() } void onUndo() { m_stack-undo(); } void onRedo() { m_stack-redo(); }兩個(gè)設(shè)置值得說明。setUndoLimit是必備的。如果不限制用戶連續(xù)操作幾小時(shí)后撤銷?？赡芾鄯e上千條命令內(nèi)存開銷和查找成本都會(huì)上升。文本編輯器可以給更大的額度圖形應(yīng)用通常 100 到 200 步就足夠因?yàn)閳D形操作的成本比文本行高得多。還有一個(gè)容易被忽略的細(xì)節(jié)push()本身就會(huì)執(zhí)行 redo()所以業(yè)務(wù)代碼里千萬不要在 push 之前先手動(dòng)調(diào)用一次 redo()否則同一個(gè)操作會(huì)被執(zhí)行兩次。這個(gè)錯(cuò)誤在團(tuán)隊(duì)協(xié)作的代碼評(píng)審里經(jīng)常出現(xiàn)因?yàn)樗粫?huì)崩潰只是數(shù)據(jù)出現(xiàn)雙重修改表現(xiàn)很隱蔽。另外stack 一般用new QUndoStack(this)掛在主窗口對(duì)象底下隨窗口生命周期走即可。如果你在一個(gè)文檔類里面使用它注意文檔關(guān)閉時(shí)要主動(dòng)清理或銷毀 stack別只刪了數(shù)據(jù)模型把棧晾在一邊。3.3 宏命令把一組操作打包成一個(gè)撤銷單元真實(shí)的應(yīng)用場(chǎng)景很少是單命令操作。用戶在屬性面板里可能一口氣改了文字內(nèi)容、字體大小、顏色然后打開預(yù)覽。如果撤銷只能回退到改顏色之前而把改文字和改字號(hào)留在歷史里體驗(yàn)很奇怪。用戶預(yù)期的是一整次屬性編輯作為一個(gè)撤銷步驟。QUndoStack 用 beginMacro / endMacro 解決這個(gè)問題m_stack-beginMacro(QStringLiteral(調(diào)整圖元屬性)); auto *cmd1 new ChangeTextCommand(m_model, itemId, oldText, newText); auto *cmd2 new ChangeSizeCommand(m_model, itemId, oldSize, newSize); auto *cmd3 new ChangeColorCommand(m_model, itemId, oldColor, newColor); m_stack-push(cmd1); m_stack-push(cmd2); m_stack-push(cmd3); m_stack-endMacro();這段代碼執(zhí)行后撤銷棧里只出現(xiàn)一個(gè)節(jié)點(diǎn)文本顯示調(diào)整圖元屬性。撤銷一次三個(gè)命令按相反順序依次 undo重做時(shí)按正序依次 redo。宏命令本質(zhì)上是構(gòu)造了一個(gè)復(fù)合的 QUndoCommand內(nèi)部自動(dòng)管理所有子命令的生命周期子命令不需要你手動(dòng)釋放。宏命令的嵌套也是允許的但建議在實(shí)際代碼里嚴(yán)格控制嵌套層級(jí)盡量避免 3 層以上否則排查歷史問題時(shí)定位成本很高。4. 集成到界面Action、歷史面板與多窗口協(xié)作4.1 用 createUndoAction 統(tǒng)一管理按鈕和快捷鍵手工維護(hù)撤銷按鈕的狀態(tài)是件麻煩事你要在每次 push、undo、redo 后檢查 canUndo() 并更新按鈕 enabled 屬性。QUndoStack 提供了現(xiàn)成的動(dòng)作工廠方法QAction *undoAction m_stack-createUndoAction(this, tr(撤銷)); QAction *redoAction m_stack-createRedoAction(this, tr(重做)); undoAction-setShortcut(QKeySequence::Undo); redoAction-setShortcut(QKeySequence::Redo); ui-undoButton-setDefaultAction(undoAction); ui-redoButton-setDefaultAction(redoAction);這里有個(gè)很貼心的細(xì)節(jié)createUndoAction 生成的 action其文本會(huì)被自動(dòng)更新為類似撤銷 移動(dòng)圖元的形式前提是命令構(gòu)造時(shí)傳了移動(dòng)圖元作為描述文本。用戶從按鈕或菜單上能直接看到下一步會(huì)被撤銷的具體操作這是很多自定義方案做不到的。動(dòng)作的 enabled 狀態(tài)同樣由 stack 自動(dòng)維護(hù)你不需要連接任何信號(hào)去做手動(dòng)更新。4.2 QUndoView給用戶一個(gè)可點(diǎn)擊的歷史面板除了工具欄上的兩個(gè)按鈕某些高級(jí)工具還會(huì)提供撤銷歷史面板讓用戶看到完整的操作記錄并可以直接點(diǎn)擊跳回任意歷史節(jié)點(diǎn)。QUndoView 是官方提供的成型組件auto *historyView new QUndoView(m_stack); historyView-setWindowTitle(tr(歷史記錄));把它放進(jìn)一個(gè)側(cè)邊?？看翱谟脩裟芸吹矫盍斜睃c(diǎn)擊任意節(jié)點(diǎn)即可把文檔回退或推進(jìn)到該位置。這個(gè)組件的底層實(shí)現(xiàn)其實(shí)就調(diào)用了 stack 的setIndex()所以你也完全可以在自己的界面里通過操作索引實(shí)現(xiàn)同樣的跳轉(zhuǎn)。4.3 QUndoGroup多文檔窗口的撤銷狀態(tài)協(xié)調(diào)多文檔編輯器下每個(gè)窗口各持有一個(gè) QUndoStack這時(shí)候麻煩來了菜單欄上只有一個(gè)撤銷按鈕到底控制哪個(gè)文檔QUndoGroup 就是用來解決這個(gè)問題的。把所有文檔的 stack 注冊(cè)進(jìn)同一個(gè) group然后由 group 統(tǒng)一暴露動(dòng)作QUndoGroup *m_undoGroup new QUndoGroup(this); void openDocument(DocumentWindow *win) { m_undoGroup-addStack(win-undoStack()); m_undoGroup-setActiveStack(win-undoStack()); }group 會(huì)跟蹤當(dāng)前活動(dòng)窗口對(duì)應(yīng)的 stack。當(dāng)用戶切換窗口時(shí)group 自動(dòng)把 activeStack 切到新窗口的 stack菜單上的撤銷和重做按鈕文案、啟停狀態(tài)隨之聯(lián)動(dòng)不需要你手工在窗口切換信號(hào)里寫一堆更新邏輯。多個(gè)動(dòng)作按鈕也需要重新綁定到 groupQAction *undoAction m_undoGroup-createUndoAction(this, tr(撤銷)); QAction *redoAction m_undoGroup-createRedoAction(this, tr(重做));還有一個(gè)加分用法QUndoGroup支持跨窗口撤銷。某些設(shè)計(jì)工具允許撤銷上一個(gè)操作即使那個(gè)操作發(fā)生在另一個(gè)文檔里用戶在多個(gè)文件之間切換操作時(shí)可以跨文檔回退。group 內(nèi)部會(huì)自動(dòng)通過setActiveStack決定當(dāng)前作用于哪個(gè)棧你只需要復(fù)用同一個(gè) undo 快捷鍵就行。5. 常見問題與排查技巧實(shí)錄5.1 撤銷后界面不刷新或者數(shù)據(jù)錯(cuò)位的排查方向撤銷操作執(zhí)行的是命令里的 undo() 邏輯它直接修改模型數(shù)據(jù)。如果視圖沒有跟著刷新通常不是 QUndoStack 的問題而是模型沒有發(fā)出正確的變更信號(hào)。命令里操作模型之后要確保調(diào)用對(duì)應(yīng)的beginResetModel()、dataChanged()、layoutChanged()等信號(hào)讓視圖重新拉取數(shù)據(jù)。一個(gè)我踩過的細(xì)節(jié)有些人在構(gòu)造命令時(shí)把模型指針存了下來但模型內(nèi)部的數(shù)據(jù)容器在操作后發(fā)生了重建比如重新加載了文件舊命令里的索引或?qū)ο笾羔樢呀?jīng)不再指向有效元素。此時(shí)撤銷一個(gè)刪除節(jié)點(diǎn)命令可能把不相關(guān)的數(shù)據(jù)刪掉。解決辦法是命令內(nèi)保存業(yè)務(wù)對(duì)象的穩(wěn)定 id 而不是指針執(zhí)行 undo / redo 時(shí)通過 id 去模型里重新查找對(duì)象。5.2 打開新文檔后歷史命令污染新數(shù)據(jù)的處理這是多文檔應(yīng)用最常見的事故。用戶在文檔 A 做了幾步操作然后打開新文檔如果文檔關(guān)閉時(shí)沒有清空 QUndoStack那么新文檔一上來就可以撤銷上一步——但執(zhí)行的是針對(duì)舊文檔的命令。undo() 里的模型指針可能恰好指向新文檔的數(shù)據(jù)結(jié)果產(chǎn)生完全錯(cuò)亂的數(shù)據(jù)。保證安全的做法是關(guān)閉文檔時(shí)顯式清理撤銷棧?？梢赃x擇把 stack 作為文檔窗口的子對(duì)象銷毀也可以在加載新文檔前調(diào)用m_stack-clear();clear()會(huì)刪除所有命令并重置 index同時(shí)自動(dòng)關(guān)閉宏命令如果正處于 beginMacro 中間的話。這行代碼建議統(tǒng)一放在文檔已加載成功之后調(diào)用避免在加載過程中出現(xiàn)不可撤銷的中間狀態(tài)。5.3 命令合并的邊界條件與高頻命令的性能問題mergeWith 寫得不好會(huì)把不該合并的命令合并掉導(dǎo)致用戶撤銷過頭。guard 條件一定要做嚴(yán)謹(jǐn)我通常要求三個(gè)條件同時(shí)滿足id 相同、操作對(duì)象相同比如圖元 id、文本指針、業(yè)務(wù)類型一致。對(duì)于不同圖元同時(shí)移動(dòng)的情況如果不比較 itemId兩個(gè)圖元的移動(dòng)命令就會(huì)被疊加成一個(gè)撤銷時(shí)就是兩個(gè)圖元一起跳表現(xiàn)非常詭異。高頻命令的另一個(gè)性能陷阱是宏命令包得過大。比如一個(gè)屬性對(duì)話框的確認(rèn)按鈕理論上應(yīng)該把用戶點(diǎn)擊確認(rèn)作為一個(gè)整體步驟但如果在拖動(dòng)滑塊的過程中就不斷 beginMacro / endMacro生成大量小型宏命令撤銷歷史會(huì)冗余。合理的做法是連續(xù) slider 拖動(dòng)期間允許命令合并等釋放鼠標(biāo)時(shí)強(qiáng)制產(chǎn)生一個(gè)邏輯斷點(diǎn)這樣既保證撤銷粒度合理又避免命令數(shù)量爆炸。5.4 撤銷棧的保存與恢復(fù)跨會(huì)話的歷史能保嗎有些軟件支持把撤銷歷史隨文檔一起保存下次打開還能繼續(xù)撤銷。QUndoStack 本身沒有內(nèi)置序列化接口你需要自己實(shí)現(xiàn)。常見做法是給每個(gè)命令增加序列化方法把命令類型、參數(shù)、時(shí)間戳寫進(jìn)文檔格式加載時(shí)重新構(gòu)造命令并 push 到新 stack 中。但這么做有個(gè)要警惕的坑恢復(fù)命令會(huì)執(zhí)行一次 redo()如果你在加載流程里把 push 當(dāng)作簡(jiǎn)單入棧處理會(huì)重復(fù)執(zhí)行命令導(dǎo)致數(shù)據(jù)疊加。所以加載歷史時(shí)要么先讓模型處于尚未加載狀態(tài)等命令依次執(zhí)行后再呈現(xiàn)要么恢復(fù)歷史前先取消命令的立即執(zhí)行行為這需要你對(duì) stack 的機(jī)制理解到位后再動(dòng)手。5.5 常見問題速查表癥狀可能原因解決思路撤銷按鈕一直是灰色的命令從未成功 push或 stack 被 clear 過檢查業(yè)務(wù)代碼是否真的調(diào)用了 push檢查宏命令是否未正確結(jié)束撤銷一步界面變化了兩步的幅度命令合并條件過于寬松收緊 mergeWith 的 guard目標(biāo)對(duì)象 id、模型指針必須一致撤銷后視圖數(shù)據(jù)錯(cuò)亂命令保存的是裸指針或舊索引改為保存業(yè)務(wù)對(duì)象 idundo/redo 時(shí)重新查找打開新文檔后能撤出舊操作舊文檔的 stack 未清空文檔加載成功后調(diào)用 stack-clear()push 后數(shù)據(jù)出現(xiàn)雙份代碼調(diào)用了兩次 redo 或重復(fù) push記住 push 自帶執(zhí)行邏輯不要二次手動(dòng)調(diào)用undo 時(shí)程序崩潰命令持有已銷毀對(duì)象的指針審視命令生命周期保證模型銷毀前清空命令棧在實(shí)際項(xiàng)目里我發(fā)現(xiàn) QUndoStack 最難的地方從來不是 API 本身而是想清楚一個(gè)命令到底應(yīng)該攜帶哪些信息、合并到什么粒度。寫命令類之前先把業(yè)務(wù)對(duì)象的身份標(biāo)識(shí)、模型的生命周期、用戶期望的撤銷粒度這三件事定下來后面的代碼基本水到渠成。如果你只是臨時(shí)解決一個(gè)編輯器的撤銷需求直接按這篇文章的示例擼一套出來足夠應(yīng)付大多數(shù)場(chǎng)景如果你的項(xiàng)目后續(xù)要做多文檔協(xié)作、持久化歷史這類高級(jí)功能也建議從第一天就把命令模式立好別等代碼堆到幾千行再回頭重構(gòu)——那時(shí)候改造成本遠(yuǎn)比你想象的高。