删除操作不必一律弹出“确定吗”。可以可靠恢复、影响较小的删除，适合执行后提供撤销或回收站；不可恢复、影响他人或会连带删除资源的操作，则应先展示对象、范围和后果，让用户明确确认。选择哪种方式，要先看真实的数据恢复能力，再决定界面形式。
界面的防误操作能力，来自“事前能识别，事后能纠正”。如果每一次删除都出现同样的弹窗，用户可能形成机械确认；如果所有删除都只给一条短暂提示，又可能来不及发现或挽回错误。下面按操作后果把两者分开。
先用三个问题判断是否需要确认
- 恢复是否真实可行？删除后能恢复对象本身，还是只能重新创建一个名字相同的新对象？关联关系、权限和历史记录是否也能恢复？
- 影响范围是否清楚？是当前一条、已勾选的几条，还是所有筛选结果？会不会影响其他成员、外部链接或自动任务？
- 代价是否容易被察觉？删除空白草稿与删除正在使用的共享资源，后果不同；用户是否有机会在造成进一步影响前发现？
| 操作特征 | 适合的方式 | 应该向用户说明什么 |
|---|---|---|
| 低影响，可完整恢复 | 执行后撤销，或移入回收站 | 已处理对象、撤销入口、后续恢复位置 |
| 可恢复，但会影响共享或工作流 | 说明影响后确认，再进入可恢复状态 | 哪些成员或任务会受影响，恢复后能否完全回到原状 |
| 不可恢复，或会连带清除数据 | 确认弹窗，必要时更明确的复核 | 对象名、数量、连带资源以及不可恢复性 |
| 只是退出且存在未保存修改 | 保留、舍弃或继续编辑的选择 | 尚未保存的是什么，不应误写成删除已存数据 |
“可恢复”必须由数据和业务规则支持。仅把列表行暂时隐藏，不能当成撤销已经实现；保留一份备份，也不意味着用户可以立刻自行恢复。
确认弹窗怎样写，用户才知道在确认什么
把模糊的“确定删除吗？”改成能识别对象的句子。标题说明动作和对象，正文解释额外后果，按钮用实际动作词。不要让标题、正文和按钮重复三次同样的空泛问题。
| 位置 | 较难判断的写法 | 更明确的写法 |
|---|---|---|
| 标题 | 操作确认 | 删除“10月活动草稿”？ |
| 正文 | 删除后可能产生影响 | 该草稿将移入回收站；已分享的预览链接将不可访问。 |
| 主按钮 | 确定 | 移入回收站 |
| 次按钮 | 否 | 取消 |
| 永久删除标题 | 温馨提示 | 永久删除这3个项目？ |
| 永久删除说明 | 请谨慎操作 | 项目内容及所列关联资料将被清除，无法在回收站恢复。 |
示例中的回收站、分享链接和关联资料，应替换成你们产品实际规则。能恢复多久就写实际期限，不能恢复就明确说不能；不要让用户从红色按钮自己猜后果。
Carbon 的模态弹窗指南将需要用户处理的重要操作与一般提示区分开。确认弹窗的价值在于帮助作决定，而不是为每一次后台请求增加一步。
撤销不是一条会消失的“成功提示”
撤销入口要回答：撤销什么、撤销到哪里、现在还能不能撤销。若系统把对象移入回收站，可以在提示中提供即时撤销，同时让回收站成为长期可发现的恢复入口。不要把唯一恢复机会压缩在用户可能没看见的短暂提示里。
- 提示明确对象，例如“已将‘10月活动草稿’移入回收站”，而不是只有“操作成功”。
- 撤销成功后，恢复对象应回到用户能理解的位置；原有排序、筛选条件是否会让它重新不可见，要给出解释或入口。
- 撤销失败时说明当前状态，不要先把界面恢复成成功样子再静默失败。
- 连续删除多个对象时，提示应与对应操作关联；不要让最后一条提示覆盖掉前几次操作的恢复机会。
- 恢复时遇到名称冲突、权限变化或关联资源已变更，应提供可执行的处理方式，而非无条件承诺完全还原。
即时撤销、回收站和版本恢复是不同能力。产品需要哪一种，就在需求中写清对象与恢复范围，避免把视觉组件当成数据机制。
批量删除，重点是范围与部分失败
后台常见风险不是点错删除按钮，而是误解“全选”。当前页20条、手动勾选20条和当前条件下的全部结果，不是同一范围。确认前要让范围能被核对，尤其是翻页后仍保留选择的情况。
| 状态 | 需要展示的内容 | 可继续的动作 |
|---|---|---|
| 选中多条 | 准确数量、当前筛选条件和选择范围 | 查看已选、取消选择 |
| 部分对象不可删除 | 不可删除的数量与可理解原因 | 移除受限对象，或取消本次操作 |
| 提交处理中 | 本次操作正在处理，避免重复发送 | 必要时查看进度；取消是否支持要明确 |
| 部分成功 | 分别列出已删除与失败数量，不用一个“成功”覆盖全部 | 重试失败项或查看原因 |
| 响应超时 | 当前结果尚未确认 | 刷新操作结果，不直接重复删除整个集合 |
可以把“尝试删除3项，2项成功，1项因权限不足失败”作为验收样本。检查成功项是否消失、失败项是否仍可查看、选择数量是否同步，以及重试是否只针对失败项。
按钮和焦点也会影响误操作
不可恢复操作的主按钮可以使用危险操作样式，但红色不能代替对象和后果。取消要容易发现，常见模态弹窗要支持合理的键盘进入、关闭和返回。
根据WAI-ARIA模态弹窗模式，不可逆步骤可以优先将初始焦点放在破坏性更小的选项。关闭后原删除入口已经不在时，焦点应转到能继续任务的位置。完整规则可在键盘导航与焦点管理中展开检查。
要求输入对象名称，可以用于少量、影响重大的操作，但不应滥用到每次普通删除。它不能替代正确的对象显示，也不能解决同名对象、名称过长或复制粘贴形成机械操作的问题。
交付研发的一页删除规则
| 规则项 | 需要填写的答案 |
|---|---|
| 对象与范围 | 删除什么；是否包含子项；影响哪些人或引用 |
| 数据动作 | 软删除、移入回收站还是永久清除 |
| 恢复能力 | 入口、期限、权限及不可恢复的部分 |
| 界面确认 | 标题、对象标识、数量、后果、按钮文案 |
| 并发与异常 | 处理中重复点击、权限变化、部分失败、超时 |
| 结束位置 | 列表怎样更新；焦点落在哪里；当前选择怎样变化 |
在墨刀原型中，把正常删除、撤销、永久删除、部分失败四种结果放在同一流程里评审。负责人可以直接对照表格补充规则，而不必从一张“确定/取消”弹窗反推业务。
用五次操作检查是否真的能防错
- 删除一条可恢复记录，再立即撤销，确认数据和可见位置都正确。
- 删除一个有相似名称的对象，确认标题或辅助信息能区分它们。
- 勾选跨页记录后打开确认，核对数量与范围。
- 让部分对象因权限或状态变化失败，确认结果没有被统一写成成功。
- 在提交后模拟超时，再回到结果页，确认不会因重试制造重复操作或错误状态。
好的删除设计让用户在需要判断时看清后果，在可以恢复时容易恢复。多一个弹窗本身不是目标，少一次无法挽回的误操作才是。
