「模態(tài)框」這種『特定狀態(tài)下的窗體』正是相對于上面敘述的這種「正常狀態(tài)」來說的。模態(tài)框是出于一種特定狀態(tài)下的窗體，它會把我們從正常狀態(tài)中中斷出來，將關(guān)注點放在這個特定狀態(tài)的處理上。可以看看模態(tài)框的實際表現(xiàn)：當(dāng)模態(tài)框出現(xiàn)的時候，它會屏蔽掉所有其他操作，用戶可關(guān)注的范圍只限于當(dāng)前的模態(tài)框內(nèi)部，除非你特意去關(guān)閉這個模態(tài)框，結(jié)束這種中斷，回到原先正常的流程中去¹。

有人認為模態(tài)框是邪惡的，給出的理由²有：

1. 阻斷信息訪問與上下文（Context Loss）

無法并行操作： 模態(tài)框強制程序進入單一模式，鎖定背景。用戶在填寫模態(tài)框時，無法查看或拷貝主窗口中的其他信息（如：想照著舊聯(lián)系人錄入新聯(lián)系人，卻因為模態(tài)框擋住了舊記錄而無法操作）。
串行處理的局限： 它強迫用戶以“串行”方式處理信息，而不能并行對比。這種“專注”往往是以犧牲靈活性為代價的。

2. 破壞用戶的工作流（Interruption of Flow）

強行奪取焦點： 模態(tài)框會突然中斷用戶的思考和操作邏輯，強制用戶必須先處理這個彈窗才能繼續(xù)。
違背非線性導(dǎo)航： Web 時代用戶習(xí)慣于非線性操作，而模態(tài)框是程序員試圖強制用戶按線性邏輯（必須先做 A 再做 B）行事的表現(xiàn)。

3. 用戶心理偏見：不閱讀，只消除

習(xí)得性忽略： 用戶養(yǎng)成了“見彈窗就點 OK”的習(xí)慣，根本不會閱讀其中的內(nèi)容。這導(dǎo)致原本為了提示風(fēng)險的彈窗失去了意義，反而可能導(dǎo)致誤操作。
認知負擔(dān)： 對于普通用戶，復(fù)雜的確認框（如“是/否/取消”）往往令其困惑。

4. 剝奪用戶的控制權(quán)（Violation of Agency）

違背用戶主導(dǎo)原則： 軟件應(yīng)由用戶主導(dǎo)，而模態(tài)框則是軟件在主導(dǎo)用戶，強迫用戶在特定時間做特定決定。
極端鎖定： 最糟糕的模態(tài)框甚至?xí)i定整個應(yīng)用程序乃至操作系統(tǒng)，讓用戶感到無助。

5. 開發(fā)者偷懶的產(chǎn)物（"Lazy" UI Design）

逃避復(fù)雜設(shè)計： 設(shè)計一個完善的“撤銷（Undo）”機制或非線性的 UI 比較困難，而彈一個模態(tài)框讓用戶確認則簡單得多。
處理邏輯的簡陋： 程序員常利用模態(tài)框來處理程序運行中的錯誤或特殊分支，而不是從產(chǎn)品設(shè)計層面優(yōu)化流程。

6. 交互效率低下

低效的重復(fù)操作： 例如在處理多個文件沖突時，如果程序逐個彈出模態(tài)框要求確認，而不是一次性列出清單讓用戶選擇，會極大地降低操作效率。

雖然上述觀點火力全開，但也提到了模態(tài)框的合理存在空間：

• 極端稀少的情況： 確實需要用戶在完成當(dāng)前任務(wù)前不得離開。
• 數(shù)據(jù)關(guān)鍵型應(yīng)用： 在企業(yè)級軟件中，為了防止災(zāi)難性的破壞操作，模態(tài)確認是必要的。
• 復(fù)雜配置任務(wù)： 如“打印設(shè)置”框，因為它集成了大量需要同時決定的選項，其邏輯獨立性較強。

替代方案建議

• 使用“撤銷（Undo）”機制： 允許用戶先操作，如果不滿意再撤銷，而不是操作前反復(fù)確認。
• 非模態(tài)通知： 使用非阻斷式的提示（如 Firefox 的保存密碼提示、信息條等）。
• 改進文案： 按鈕直接描述動作（如“刪除”、“保存”），而非含義模糊的“確定”。
• 批量處理： 將多次確認合并為一次操作。

參考1：https://blog.csdn.net/qq_27607579/article/details/84837734
參考2：https://stackoverflow.com/questions/361493/why-are-modal-dialog-boxes-evil