提交成功需要明确的确认反馈，而非静默跳转
别名: 提交成功反馈 · silent redirect · 成功确认
概念解释
请求已经成功写入，人却被送到一张看起来像「还没填」的新页，或原来那张表被清空，没有一句「已经收到」。明确的确认是提交成功之后、在下一动作之前，让人能核对「这件事成了」的反馈：成功页、横幅加单号、或就地变成只读结果。静默跳转把成功编码成路由变化，人读成刷新失败或没点上。长时间处理要不要转圈、成功页上下一步是什么、部分字段失败怎么拆，是后面三步。禁用按钮挡住连点，也不等于告诉人已经成功。
机制
提交是一次不可见的状态跃迁：本地的「正在填」变成远端的「已存在」。人用来确认跃迁的是界面里多出来的那句结果，不是 URL。静默跳到列表或首页时，新页面没有指向刚才那次提交的锚，工作记忆里的「我刚送出一份申请」对不上任何对象，人会再走一遍表单。第二层是清空当成失败：成功后把表单 reset 成空，看起来和校验失败刷新一样。没有单号、时间或「已提交给谁」这类可核对物，确认无法事后检索，也无法向客服引用。跳转可以发生，但必须带着成功语义一起落地，而不是用落地本身冒充成功语义。
怎么研究
比较「成功页带单号」「跳到列表无说明」「就地清空无文案」「吐司 2 秒后消失再跳转」。任务是提交后回答「成了没有、凭证是什么」。
自变量：确认形态（成功页 / 带说明的跳转 / 静默跳转 / 短吐司）、是否有可复制的单号、原表是否被清空。 因变量：误以为失败而重提、能否说出凭证、事后能否在界面里找到刚才那一次。
实验室里下一任务就是确认，会高估吐司。要加打断（提交后立刻切走再回来）。不要把「到达了下一 URL」当成确认成功。
边界
连续录入（仓库扫码一项接一项）里，成功可以是就地一条短确认并立刻聚焦下一空，但仍要有可回看的记录，不能什么都不留。嵌入式保存（文档里的自动保存）不是提交，不走这条。登录成功进首页是会话开始，可用「已登录为谁」代替申请单号。静默跳转若目标页第一屏就是刚才那条新记录并高亮，确认物在对象上，伤害下降——但仍应有「已创建」而不只是列表多了一行。
怎么落地
- 成功之后落地在带成功语义的界面：标题或横幅写「已提交 / 已创建」，并给出可核对的单号或时间。
- 不要在无说明的情况下清空原表或跳到通用首页；若必须跳列表，高亮新记录并写一句已创建。
- 吐司不能当唯一确认；人切走再回来仍要能在界面里找到那一次。
- 验证：提交后立刻问「成了没有、凭证是什么」；答不出即失败。切走再打开产品，能否凭单号找到记录。做静默跳首页、原表被清空的对照，统计重提次数。