H7.05.3savable order confirmation设计研究
确认信息需可保存与查询
别名: 订单可查 · 保存凭证 · order history lookup
概念解释
成功页上的字段不能只活在这一次会话里。可保存与查询指人离开之后，仍能用订单号、账号或邮件里的链接把同一份确认找回来：商品、金额、时间、状态。保存可以是下载、截图友好的版式、或系统替人归档；查询是「我的订单」里用同一标识能命中。这条不管发票的法律效力，也不管多个下单渠道要不要归到一个历史——那是凭证体系；这里只要这一次确认不会随页面关掉而消失。
机制
人不会把订单号记在工作记忆里。关闭标签、换设备、客服要求报号时，如果确认只存在于刚才那一屏，就等于没有确认。邮件和短信是常见的外部记忆，但它们会进垃圾箱、延迟、或被换成营销模板。查询入口必须用与成功页相同的号，否则人拿着号也搜不到。游客订单尤其脆弱：没有账号树，号和邮箱是唯一钥匙，过期链接会把购买变成传说。
怎么研究
让人完成支付、关掉成功页，隔一段时间用不同入口找回：订单列表、邮箱链接、仅订单号。比较有持久记录与仅会话页。
自变量：是否写入订单列表、邮件是否含完整字段、游客凭邮箱+号能否查、链接有效期。 因变量：找回成功率、找回耗时、因找不到单号进线。
实验室当场点「查看订单」测不到隔日查询。要用隔夜和第二个设备。不要把「邮件已发送」日志当成用户可查——要真的打开收件箱。
边界
无账号且拒填邮箱的购买，保存只能靠当场下载或系统分享到本地；要在离开前提示「关掉就找不到」。受监管需要保留交易记录的商家，查询时限可能长于产品展示策略，界面不能先把记录藏起来。被风控隐藏的订单对用户仍应可查，至少看到「处理中」而不是 404。
怎么落地
- 支付成功即写入可登录的订单列表，成功页提供复制订单号、下载或系统分享。
- 发送的邮件或消息含与成功页一致的号和金额，主题里能搜到订单号。
- 游客给出「邮箱 + 订单号」查询页，并在成功页说明这两样要自己留存。
- 验证：付完关掉成功页，隔日用第二个设备只凭邮件或订单列表找回；游客路径只用邮箱和号。找不到或字段对不上，保存失败。