移动网络断开后，用户可能不知道提交是否成功。接口必须让重试和状态恢复有明确语义。
本文使用移动产品的假设案例与手工经营模型。这里讨论产品验证方法，不叙述未经记录的创业成绩。用户、订单和费用均为演算变量；商业假设需要访谈、行为数据与真实交易分别支持。
1. 从现象推到机制
客户端生成稳定请求身份，服务端保存处理状态，页面可以查询结果。读取接口与写入接口的重试风险不同。列表分页还要考虑新数据插入带来的重复和遗漏，不能把网络问题全部交给无限重试。
图中的四个节点分别表示用户提交、服务端处理、弱网中断、查询恢复。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
围绕一个演示订单定义创建和查询接口，约定请求超时后先查已有身份。服务端再次收到相同请求时返回同一业务对象。
1
2
3
POST /orders request_id, item_id, quantity
GET /orders/by-request/{request_id}
# request_id 在同一次业务重试中保持稳定
先把计算过程放入一张普通表格，保留原始分母、时间范围和渠道。改变一个变量观察结果，再用实际采样替换假设值；没有观测数据的地方应保持待验证。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 请求已处理但响应断开 | 查询能够恢复同一订单 |
| 用户连续点击提交 | 不应创建多份相同订单 |
| 列表期间插入新记录 | 翻页需要稳定排序规则 |
对照 1：请求已处理但响应断开
查询能够恢复同一订单。观察时记录请求身份与订单映射。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：用户连续点击提交
不应创建多份相同订单。观察时记录服务端唯一约束。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：列表期间插入新记录
翻页需要稳定排序规则。观察时记录分页游标与实际顺序。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
客户端本地状态只是体验层提示。是否提交成功要能由服务端验证；离线暂存还需明确保存期限与用户可撤销范围。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“列表期间插入新记录”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
