如果用户每删一条草稿都要弹“确定吗？真的确定吗？”，很快就会形成无意识点击确认；而删除整个组织如果只给一个 3 秒 Undo，又可能造成不可接受损失。危险操作的设计核心是后果、可逆性和影响范围。
01 先判断后果是否可逆，再决定要不要打断
如果删除只是移入回收站，用户可以在 30 天内恢复，操作后提供 Undo 往往比操作前弹 Modal 更顺畅。
如果行为会永久删除数据、影响其他成员或产生费用，则更适合在行动前确认。确认不是仪式，而是给用户理解后果的最后机会。
02 频繁低风险操作不要用重复确认训练用户“无脑点确定”
当用户每天删除几十条草稿，每次都弹同样对话框，他很快会自动点击右侧主按钮。真正高风险操作出现时，确认也失去保护作用。
低风险操作可以直接执行并提供撤销；高风险才提高摩擦。设计摩擦应该与损失成比例。
03 确认文案要写具体对象和后果
“确定删除吗？”信息很弱。“删除项目 Apollo 后，12 名成员将无法访问，相关自动化将停止”更能支持判断。
按钮也不要写“确定 / 取消”，而写“删除项目 / 保留项目”。用户快速扫一眼就知道哪个动作危险。
04 输入名称确认只适合极高风险、低频操作
要求输入组织名、项目名或 DELETE 可以有效降低误触，但它是高摩擦方式。适合删除组织、生产环境数据库等后果严重行为。
不要把输入确认泛化到每个删除，否则用户会复制粘贴并继续无脑操作。
05 批量操作必须显示影响数量和范围
“删除所选”如果用户忘了自己跨页选中了 438 条数据，风险极高。确认区域应显示数量，必要时说明跨筛选或跨页面选择。
批量操作完成后，如果支持恢复，应该保留清晰恢复入口，而不是只显示“操作成功”。
06 软删除和恢复期是产品策略，不只是 UX 组件
很多删除可以先进入 Trash，在一定时间后真正清理。这样用户体验更安全，也降低客服恢复数据成本。
但涉及隐私和合规时，恢复期、真正删除时间和备份策略必须与法律、安全团队确认，不能由设计师凭体验偏好决定。
07 权限和身份验证可以作为额外保护层
删除整个工作区可能要求管理员权限；修改付款账户可能要求再次验证身份。
这类保护比再弹一个视觉 Modal 更有效，因为它限制了谁能执行，而不是只问执行者“你确定吗”。
08 操作后要给用户明确结果，而不是让列表突然少一行
执行成功后说明对象已删除、是否可以恢复、恢复入口在哪里；失败时解释原因。
危险操作的完整体验包括预防、执行和恢复三段。只设计一个红色按钮和确认框，远远不够。
09 默认按钮位置要避免确认和取消过于相似
危险确认框中，破坏性按钮应有明确标签与视觉语义，取消则保持普通样式。不要两个按钮同样高亮，只靠左右位置区分。
不同平台对主按钮位置习惯不同，设计系统应统一规则，避免用户靠肌肉记忆时误触。
10 连续危险操作需要节流和权限控制
批量删除后立刻再次删除、短时间连续修改支付设置，可能是误操作也可能是账号风险。产品可以通过速率限制、重新认证或延迟生效提供额外保护。
这些属于安全与产品策略，但 UX 需要提前表达限制和原因。
11 恢复入口要真正可发现
如果删除后只在 5 秒 Toast 里提供 Undo，用户错过后再也找不到 Trash，形式上可撤销，实际上仍接近不可逆。
重要资源可以提供独立回收站、恢复期说明和搜索，让恢复能力成为可靠机制。
常见问题
删除操作一定要二次确认吗？
不一定。可轻松撤销的低风险删除可直接执行并提供 Undo，高风险不可逆操作更适合确认。
Undo 显示几秒合适？
取决于任务和恢复机制。如果真正可从回收站恢复，就不必把唯一恢复机会限制在几秒内。
什么时候要求输入对象名称确认？
适合删除组织、生产环境等极高风险且低频行为。
红色按钮就足以表示危险吗？
不够。还应有明确文案、后果说明和可访问的语义，不能只依赖颜色。
批量删除最重要显示什么？
至少明确对象数量、范围和是否可恢复，避免用户误以为只删除当前屏。
相关服务与进一步咨询
链接复制成功
