撤销窗口时长与后果等级挂钩
别名: 撤销窗口 · undo window · 分级撤销期
概念解释
撤销窗口指一次操作完成后，仍允许用户把它收回的那段时间。这条讲的是这段时间该定多长：不该在整个产品里用同一个数字（比如统一给5秒、统一给24小时），而应该按每个操作后果的严重程度分级设定——后果轻的操作给短窗口，后果重、影响持久的操作给长得多的窗口，甚至需要额外的通知机制来配合。
机制
撤销窗口能不能真正起作用，取决于用户"意识到需要撤销"的那一刻是否落在窗口之内，而不是操作发生后固定过去多久。对后果轻微的操作（归档一封邮件、静音一个通知），用户如果几秒内没反应，大概率说明这次操作确实是他想要的，短窗口已经覆盖了几乎所有真实的犹豫时刻。但对后果重大或影响滞后显现的操作（取消订阅、注销账号、删除一份很久不会再打开的文件），用户发现"我不是真的想这么做"的时刻可能远远晚于操作本身——可能是几天后收到订阅到期提醒才想起来，也可能是几周后需要用到那份文件才意识到删错了。如果撤销窗口按统一的短时长设定，这类操作的撤销窗口在用户真正意识到问题之前就已经关闭，窗口存在与不存在没有区别。
边界
这条原则不适用于窗口期内动作已经产生了无法内部收回的外部效果的场景——即使把窗口拉得很长，如果操作在发生的瞬间就已经把效果传递到了系统边界之外（消息已读、资金已经到达对方账户），窗口时长本身解决不了外部效果收不回来的问题，此时应该处理的是能否补救而不是窗口该设多久。
怎么落地
把产品里的撤销类操作按后果严重度分成明确的档位而不是逐个操作单独定一个数字：轻微且高频的操作用几秒到几十秒的即时撤销提示；中等后果的操作用几天到一个月的可恢复期（比如回收站）；后果重大或用户可能很晚才发现问题的操作，用更长的宽限期并配合主动提醒（订阅取消前发提醒、账号注销前发确认邮件），而不是让用户自己想起来去检查。定这个时长的依据应该是"用户平均需要多久才会意识到这次操作有问题"，不是随手抄一个别的功能已经在用的默认值。验证办法：对每一类撤销操作，统计用户实际点击撤销的时间点分布——如果相当比例的撤销请求发生在窗口关闭之后（用户联系客服要求恢复），说明窗口定得太短，没有覆盖真实的发现延迟，需要按这个分布重新校准时长。