「模态框」这种『特定状态下的窗体』正是相对于上面叙述的这种「正常状态」来说的。模态框是出于一种特定状态下的窗体，它会把我们从正常状态中中断出来，将关注点放在这个特定状态的处理上。可以看看模态框的实际表现：当模态框出现的时候，它会屏蔽掉所有其他操作，用户可关注的范围只限于当前的模态框内部，除非你特意去关闭这个模态框，结束这种中断，回到原先正常的流程中去1。
有人认为模态框是邪恶的，给出的理由2有：
1. 阻断信息访问与上下文（Context Loss）
无法并行操作： 模态框强制程序进入单一模式，锁定背景。用户在填写模态框时，无法查看或拷贝主窗口中的其他信息（如：想照着旧联系人录入新联系人，却因为模态框挡住了旧记录而无法操作）。
串行处理的局限： 它强迫用户以“串行”方式处理信息，而不能并行对比。这种“专注”往往是以牺牲灵活性为代价的。
2. 破坏用户的工作流（Interruption of Flow）
强行夺取焦点： 模态框会突然中断用户的思考和操作逻辑，强制用户必须先处理这个弹窗才能继续。
违背非线性导航： Web 时代用户习惯于非线性操作，而模态框是程序员试图强制用户按线性逻辑（必须先做 A 再做 B）行事的表现。
3. 用户心理偏见：不阅读，只消除
习得性忽略： 用户养成了“见弹窗就点 OK”的习惯，根本不会阅读其中的内容。这导致原本为了提示风险的弹窗失去了意义，反而可能导致误操作。
认知负担： 对于普通用户，复杂的确认框（如“是/否/取消”）往往令其困惑。
4. 剥夺用户的控制权（Violation of Agency）
违背用户主导原则： 软件应由用户主导，而模态框则是软件在主导用户，强迫用户在特定时间做特定决定。
极端锁定： 最糟糕的模态框甚至会锁定整个应用程序乃至操作系统，让用户感到无助。
5. 开发者偷懒的产物（"Lazy" UI Design）
逃避复杂设计： 设计一个完善的“撤销（Undo）”机制或非线性的 UI 比较困难，而弹一个模态框让用户确认则简单得多。
处理逻辑的简陋： 程序员常利用模态框来处理程序运行中的错误或特殊分支，而不是从产品设计层面优化流程。
6. 交互效率低下
低效的重复操作： 例如在处理多个文件冲突时，如果程序逐个弹出模态框要求确认，而不是一次性列出清单让用户选择，会极大地降低操作效率。
虽然上述观点火力全开，但也提到了模态框的合理存在空间：
- 极端稀少的情况： 确实需要用户在完成当前任务前不得离开。
- 数据关键型应用： 在企业级软件中，为了防止灾难性的破坏操作，模态确认是必要的。
- 复杂配置任务： 如“打印设置”框，因为它集成了大量需要同时决定的选项，其逻辑独立性较强。
替代方案建议
- 使用“撤销（Undo）”机制： 允许用户先操作，如果不满意再撤销，而不是操作前反复确认。
- 非模态通知： 使用非阻断式的提示（如 Firefox 的保存密码提示、信息条等）。
- 改进文案： 按钮直接描述动作（如“删除”、“保存”），而非含义模糊的“确定”。
- 批量处理： 将多次确认合并为一次操作。
参考1：https://blog.csdn.net/qq_27607579/article/details/84837734
参考2：https://stackoverflow.com/questions/361493/why-are-modal-dialog-boxes-evil
