鸿沟表现为不知道是否成功
别名: 不确定成功 · 重复提交 · 结果不明 · 因果证据
概念解释
评估鸿沟（Gulf of Evaluation）常见于"我提交了吗？保存了吗？发给谁了？失败了吗？"用户无法从界面判断操作是否生效、完成到哪一步、结果是否可撤销。这会引发重复提交、无谓等待或错误继续。这一条紧接在"评估鸿沟是系统状态与用户理解之间的距离"之后：上一条给出了鸿沟的一般定义，这一条聚焦在这条鸿沟出现频率最高、后果也最直接的一种具体场景——提交类动作之后，用户完全没有因果证据可以依靠。
机制
用户判断"是否成功"，靠的不是相信系统内部真的处理完了，而是靠界面提供的因果证据——某个动作发生后，紧跟着出现了什么可以被感知到的变化，这个变化在用户心里就成了"我的操作确实生效了"的证明。问题在于，提交之后的真实系统状态往往横跨请求队列、服务端处理、缓存同步和通知推送好几层，这几层各自完成的时间点并不一致；如果界面唯一给出的反馈只是"弹窗消失了"或者"按钮转了一圈又停下"，这种反馈和背后真正发生的处理过程之间没有建立起可靠的因果关系——弹窗消失可能只代表前端收到了请求，不代表后端真的处理完成，用户却会把它当成完成的证据。乐观更新、异步审批、部分成功和外部系统延迟进一步让"成功"这个词本身变得不再是一个单一状态，而是需要拆成"已接收""已处理""已发布""已同步"这几个不同阶段；如果界面用的状态词汇没有把这几个阶段区分开，用户拿到的信息永远是模糊的，这时候他们会本能地按最坏的可能性去行动——也就是重新提交一遍，因为重复提交的代价（可能造成重复记录）在用户看来，往往小于"什么都不做，结果其实没成功"的代价。
边界
不能因为状态还不确定就干脆显示一个假的"成功"。如果请求确实还没有得到确认，诚实的做法是显示"已发送，等待确认"这类明确表达不确定性的状态，并且提供一个可以随时回去查看最新状态的入口，而不是为了让用户安心就提前展示一个尚未真正发生的结果；一旦这个提前展示的"成功"后来被推翻，用户遭受的信任伤害会比一直诚实显示"处理中"更大。部分完成的情况也需要单独处理：批量操作里有的对象成功、有的失败、有的被跳过，界面必须把这三类分别列出来，而不能笼统地报一个"已完成"了事，那样会把失败和跳过的部分永久遗漏在用户的认知之外。反过来，低风险、几乎瞬时完成的操作不需要一个大而醒目的确认页面去反复强调"成功了"，但即使不需要醒目提示，操作留下的痕迹依然必须是可以事后回查的，不能因为动作小就完全不留状态记录。
怎么落地
- 对提交、保存、发送和同步这几类高频动作，分别定义清楚的结果状态词汇和对应的时间戳，不要让"完成""成功""已处理"这类词交替使用却指代不同的事情。
- 完成提示里包含具体的对象、数量、接收者或者目标存放位置，并且提供一个可以点进去查看详情的入口，而不是只给一句抽象的"操作成功"。
- 异步任务要支持用户离开页面之后再回来查看当时的处理结果，处理失败时要给出具体原因和重试入口。
- 验证办法：专门测试弱网环境和"提交后立刻切走再返回"这种中断场景，检查用户回来之后能不能准确判断自己刚才的操作到底有没有生效、要不要重新提交——如果用户在这种测试里选择了重复提交，说明当前的状态反馈没能提供足够的因果证据。